Question de base: Si je ne peux pas modifier la procédure d'appel du programme appelant, puis-je toujours traduire le code source d'origine d'une DLL de Fortran 77 vers VB.Net? Par exemple, est-il possible de faire en sorte qu'une DLL écrite en VB.NET se comporte de manière identique à celle dont le code source a été écrit à l'origine dans Fortran 77?Traduction de la DLL Fortran vers la DLL VB.NET
Je sais que je vais rencontrer des problèmes avec les chaînes. Mais aucune de mes procédures n'aura d'entrées/sorties de chaînes, seulement des entiers de 4 octets et des doubles de 8 octets.
Je dois modifier une DLL écrite à l'origine dans Fortran 77. Pour faciliter les changements futurs, je voudrais traduire le code source DLL de Fortran à VB.Net. Je ne peux pas modifier le programme qui appelle la DLL, et je n'ai pas le code pour le programme qui appelle la DLL, donc je ne sais pas comment il appelle. Tout d'abord, est ce que j'essaie de faire possible? Je pense que c'est parce qu'une DLL est une DLL indépendamment de la langue source, non? C'est là où je suis:
Le code source Fortran ressemble à ceci:
subroutine init(dwid)
use dfport
implicit none
common /fltcmn/ ifirst, icnt
integer ifirst, icnt
integer(4) dwid
external fndndx
cDEC$ ATTRIBUTES C, REFERENCE, DLLEXPORT, ALIAS:'_INIT' :: INIT
[code in here w/ return]
end subroutine init
function fndndx(dwid)
use dfport
implicit none
common /fltcmn/ ifirst, icnt
integer ifirst, icnt, fndndx
integer(4) dwid
[code in here w/ return]
end function fndndx
Et suit maintenant ma tentative de traduire (ce qui ne fonctionne pas en ce moment)
Public Class Class1
Public ifirst as Integer
Public icnt as Integer
Sub init(ByVal dwid as Integer)
[Code in here w/ return]
End Sub
Function fndndx(ByVal dwid as Integer) as Integer
[Code in here w/ return]
End Function
End Class
Je suis assez confiant que [le code ici w/return] est correct puisqu'il s'agit d'instructions logiques de base. Cependant, ce dont je ne suis pas sûr, c'est si je traite correctement les instructions "communes" de Fortran, et si les fonctions et sous-routines sont correctes dans une "Classe" ...
Vous dites, "pour faciliter les changements futurs". Mais qui est le plus susceptible d'avoir un avenir, et d'être répandu? Fortran, ou VB? VB est né en 1991. Fortran a réussi à survivre 40 années de plus, est une norme activement améliorée (Fortran 66, 77, 90, 95, 2003, 2008 et 2015), il y a beaucoup de compilateurs sur lesquels compter, pas seulement un, et il y a de bons compilateurs libres (gfortran, open64) ... Oh, et en passant, si c'est une DLL, ça peut aussi être lié à VB comme à tout, pas vraiment besoin de traduire. –
Etes-vous en train de dire que c'est la source FORTRAN originale et que "[Code ici avec retour]" compile et fait quelque chose? Bon ... ça fait longtemps que je n'ai pas codé en FORTRAN mais j'ai l'impression que ce code ne fait rien. En ce qui concerne les classes, ce n'est pas un marché du tout; ce sont de simples contenants que, dans le pire des cas, il vous suffirait d'inclure dans vos appels. – varocarbas
@arbautjc Je voulais dire plus facile pour les utilisateurs comme moi, avec plus d'expérience avec vb.net. Autant que je veux devenir plus courant dans Fortran, le temps est seulement tellement. Le code ne résout pas les problèmes de maths, mais les instructions logiques résultant des actions dans un programme, ce qui à mon avis VB est un peu plus convivial dans cet aspect. – Esteban