Fortran适合科学计算，界面交给Tcl/TK、PureBasic！

fcode

这几个图看起来很不错，是一个好选择。

确实没必要什么事情都用同一个语言或构架来完成，混编不是一件麻烦的事情。我曾见过一个老外用 VC++ & OpenInventor & Fortran 做的效果特别棒。

fcode

如果 TCL 可以调用其他语言的 DLL，没道理不能调用 Fortran 产生的。

如果 TCL 本身就是有跨平台的成分，那么语法里可能没有 DLL 相关的东西。

fcode

lm_lxt 发表于 2014-1-26 19:21
Tcl/TK可以和C/C++语言编写的dll进行良好沟通。但是对于Fortran，目前还不清楚有什么方法。 ...

DLL 做为一种操作系统的可执行文件来说，只有二进制语法，是没有语言特征的。

顶多在调用协定上有一些差别。不应该出现这种 C 的 DLL 可用，而 Fortran 的 DLL 不可以的情况。

fcode

lm_lxt 发表于 2014-1-26 19:31
C的dll调用，我做过相应的例子。
至于Fortran的，有空再看。

我觉得应该是不存在问题的。或者说，这些问题应该可以解决。
话说，假如你给我一个DLL，让我判断这是 C 编译出来的，还是 Fortran 编译出来的，我恐怕都不敢保证100%判断正确。

fcode

OpenWindow 然后无限 WaitEvent，这就有点Win32 SDK编程的意思了。

fcode

jason388 发表于 2014-1-30 08:31
实际上，如果自己用，界面真的不是太重要。如果为了数据可视化，可以用gnuplot和paraview。开发界面还是要 ...

自己用当然不重要。
如果是公开给别人使用，有一个界面可能更方便。

关于界面有多种解决方案。不止调用exe，dll和lib都可以有。

不管怎么样，如果有一个fortran编译器厂家可以把界面的东西封装得很好，像MFC那样，才应该是最好的解决方案。

其实像楼主介绍的这种，调用exe，通过管道互通，也是不错的方式。我们的IDE和编译器，大多数就是这种关系。

fcode

lm_lxt 发表于 2014-1-31 20:15
这样的话代码参数传递方便很多，GUI响应速度会更高，但是开发效率一般。 ...

那岂不是 C 的编译器和 Fortran 编译器要捆绑销售了？呵呵...
开发效率和执行效率总是不能兼得。
PS：祝新年好！

fcode

lm_lxt 发表于 2014-1-31 20:20
自己用能加上一点前后处理用起来也方便，比如通过界面将结果写入excel总比从记事本或者UE中粘贴到excel中 ...

嗯，能做后处理，确实方便些。

我现在一般的解决方案是：
1.如果数据不大，一般的曲线，用 Winteracter 成图，三四个函数就可以了。封装得挺到位。
2.只给自己看的话，用 MathCAD 或 Grapher 一类的软件，数据改变时，图形就自动改变了。
3.我还没有必须使用Excel的这种开发要求，一般csv就可以满足要求。

fcode

lm_lxt 发表于 2014-1-31 20:30
调用dll应该是正规的做法。

关于界面，原来偏向于桌面的概念似乎慢慢在弱化，网页UI越来越受到重视，或 ...

桌面软件有很多弊病，升级问题，安全问题（盗版）之类的。
应该慢慢会被基于浏览器的应用而替代。
将来的应用程序应该是，HTML一类的前台页面响应用户操作和数据，图形。服务器云端后台计算。
目前来说，数据大量交换可能是个问题，但会很快解决。

fcode

lm_lxt 发表于 2014-1-31 20:39
所以学习fortran的同时似乎应该了解一些HTML、Javascript、AJAX以及PHP之类的东西。
当然数值算法唯上的 ...

我以前倒是了解一些HTML，Javascript，CSS，ASP，水平还凑合够用。
后来，Ajax，Json，PHP 流行的时代，没跟上。最近恶补了一把。懂了点点皮毛。

这些架构的东西还有一个好处，跨平台效果比较好。
就算计算程序内核是在 Linux 上写的，只要主机是Linux跑得起来，前台页面适合所有操作系统。每一个操作系统的用户都可以使用。