Qu'est-ce que l'explicite la différence entre le fortran intentions (in,out,inout)?

Intentions sont juste des conseils pour le compilateur, et vous pouvez jeter que des informations de distance et de la violer. Les intentions existe presque entièrement à assurez-vous que vous ne faites que ce que vous avez prévu de le faire dans une sous-routine. Un compilateur peut choisir de faire confiance à vous et optimiser quelque chose.

Cela signifie que intent(in) n'est pas le passage par valeur. Vous pouvez toujours remplacer la valeur d'origine.

program xxxx  
    integer i  
    i = 9  
    call sub(i)  
    print*,i ! will print 7 on all compilers I checked  
end  
subroutine sub(i)  
    integer,intent(in) :: i  
    call sub2(i)  
end  
subroutine sub2(i)  
    implicit none  
    integer i  
    i = 7  ! This works since the "intent" information was lost.  
end

program xxxx  
    integer i  
    i = 9  
    call sub(i)  
end  
subroutine sub(i)  
    integer,intent(out) :: i  
    call sub2(i)  
end  
subroutine sub2(i)  
    implicit none   
    integer i  
    print*,i ! will print 9 on all compilers I checked, even though intent was "out" above.  
end  

OriginalL'auteur The Glazer Guy

Il n'est pas clair si les pièces de l'OP questions ont été effectivement répondu. En outre, certainement il semble y avoir beaucoup de confusion et d'erreurs dans les réponses/discussions qui pourraient bénéficier de quelques précisions.

A) L'OP la question de Re

" puis je veux aussi savoir pourquoi on veut utiliser intent(out), depuis la intent(inout) exige moins de travail (pas de copie de données)."

peut ne pas avoir de réponse, ou au moins trop directement/correctement.

Tout d'abord, pour être clair de la Intent attributs ont au moins DEUX raisons: "d'hygiène et de sécurité", et "indirecte" performance " problèmes (et non pas "direct performance").

1) d'Hygiène et de Sécurité: pour aider À la production de "coffre-fort/sensible" code avec la réduction de la possibilité de "désordre des choses". Ainsi, un Intent(In) ne peut pas être remplacé (au moins localement, ou même "globalement" dans certaines circonstances, voir ci-dessous).

De même, Intent(Out) exige que l'Arg être assignée à une "réponse explicite", contribuant ainsi à réduire les "déchets" des résultats.

Par exemple, dans la solution de peut-être le problème le plus commun en mathématiques appliquées, à savoir la soi-disant "Ax=b problème", le "résultat direct/réponse" on est à la recherche pour les valeurs du vecteur x. Ceux-ci devraient être Intent(Out) pour s'assurer de x est affecté "explicite" réponse. Si x a été déclaré que, disons, Intent(InOut) ou "pas l'Intention", puis Fortran attribuer, pour x certaines "valeurs par défaut" (probablement "zéro" en mode Debug, mais les chances de "déchets" dans le mode de Libération, d'être tout ce qui est dans la mémoire à l'Args emplacement du pointeur), et si l'utilisateur n'a pas alors d'assigner les valeurs correctes pour x explicitement, il serait de retour "ordures". La Intent(Out) serait "rappeler/force" à l'utilisateur d'attribuer de manière explicite les valeurs de x, et donc évite ce genre de "(accidentelle) de la foutaise".

Pendant le processus de solution, on pourrait (presque sûrement) de produire l'inverse de la matrice A. L'utilisateur peut retourner son inverse à l'appel de la s/r au lieu d'Un, dans ce cas doit être Intent(InOut).

Alternativement, l'utilisateur peut s'assurer qu'aucune des modifications sont apportées à la matrice ou du vecteur b, dans ce cas, ils seraient déclarés Intent(In), et ainsi de s'assurer que les valeurs critiques ne sont pas remplacés.

2) "Indirecte" Performance " (et "global d'hygiène et de sécurité"): Même si les Intentions ne sont pas directement pour influer sur les performances, ils le sont indirectement. Notamment, de certains types de l'optimisation, et en particulier le Fortran Pure et Élémentaire des constructions, peut produire des performances nettement améliorées. Ces paramètres nécessitent généralement tous les Arguments pour avoir leur Intention déclarée de manière explicite.

Grosso modo, si le compilateur sait à l'avance de l'Intention de tous les vars, alors il peut optimiser et "la bêtise cochez la case" le code avec plus de facilité et d'efficacité.

Surtout, si l'on utilise Pur etc constructions, puis, avec une forte probabilité, il y aura un "genre de d'hygiène et de sécurité" ainsi, depuis la Pure/Élémentaire s/p s ne peut en appeler d'autres Pur/Élémentaire s/p et donc on NE peut pas arriver à une situation de la sorte il l'est indiqué dans Le Glazer Gars" exemple.

Par exemple, si Sub1() est déclarée comme Pure, puis Sub2() doit également être déclaré Pur, et alors il sera tenu de déclarer les Intentions à tous les niveaux, et donc les "déchets" produits dans "Les Glazer Gars" exemple ne pouvait PAS se produire. Qui est, le code serait:

Pure subroutine sub_P(i)
    integer,intent(in) :: i
    call sub2_P(i)
end  subroutine sub_P

Pure subroutine sub2_P(i)
    implicit none
!        integer i          ! not permitted to omit Intent in a Pure s/p
    integer,intent(in) :: i
    i = 7   ! This WILL NOT WORK/HAPPEN, since Pure obviates the possibility of omitting Intent, and Intent(In) prohibits assignment ... so "i" remains "safe".
end  subroutine sub2_P

... sur la compilation, ce serait de produire quelque chose comme

" ||Erreur: argument 'i' avec INTENT(IN) dans la définition de la variable de contexte (affectation) à (1)| "

Bien sûr, sub2 n'a pas besoin d'être Pur, je n'ai déclaré que Intent(In), ce qui donnerait le "hygiène et de sécurité" que l'on recherche.

Avis que, même si j'ai été déclaré Intent(InOut), il serait encore échouer avec Pure. Qui est:

Pure subroutine sub_P(i)
    integer,intent(in) :: i
    call sub2_P(i)
end  subroutine sub_P

Pure subroutine sub2_P(i)
    implicit none
    integer,intent(inOut) :: i
    i = 7   ! This WILL NOT WORK, since Pure obviates the possibility of "mixing" Intent's.
end  subroutine sub2_P

... sur la compilation, ce serait de produire quelque chose comme

"||Erreur: argument 'i' avec INTENT(IN) dans la définition de la variable de contexte (argument réel à l'INTENTION = OUT/INOUT) à (1)|"

Ainsi, stricte ou large autonomie sur Pur/Élémentaire des constructions sera de s'assurer (pour la plupart) "global d'hygiène et de sécurité".

Il ne sera pas possible de l'utiliser Pur/Élémentaire etc dans tous les cas (par exemple, de nombreux mixte paramètres de langue, ou, lorsqu'ils s'appuient sur des libs externes au-delà de votre contrôle, etc).

Encore, l'utilisation cohérente des Intentions du monde, et chaque fois que possible Pur etc, va produire beaucoup d'avantages, et d'éliminer beaucoup de chagrin.

On peut tout simplement prendre l'habitude de déclarer les Intentions de partout, tout le temps quand c'est possible, qu'il soit Pur ou pas ... c'est le recommandé pratiques de codage.

... cela met aussi en évidence une autre raison pour l'existence de DEUX Intent(InOut) et Intent(Out), depuis Pure doit disposer de tous les Arg est de l'Intention déclarée, il y a des Arguments qui sont seuls, tandis que d'autres sont InOut (c'est à dire qu'il serait difficile d'avoir Pure sans chacun de In, InOut et Out Intentions).

2 b) de L'OP commentaires attend à "des améliorations de performances "depuis le pas de la copie est nécessaire" indique un manque de compréhension de Fortran et son utilisation extensive de passage par référence. Passé par référence signifie, pour l'essentiel, seuls les pointeurs sont nécessaires, et en fait, souvent, seul le pointeur vers le premier élément dans un tableau (plus quelques peu caché array info) est nécessaire.

En effet, quelques indications peuvent être offerts par l'examen de "l'ancien temps" (par exemple Fortran IV, 77, etc), lors du passage d'un tableau peuvent avoir été codé comme suit:

Real*8 A(1000)

Call Sub(A)

Subroutine Sub(A)

Real*8 A(1) ! this was workable since Fortran only passes the pointer/by ref to the first element of A(1000)
                ! modern Fortran may well throw a bounds check warning

Moderne Fortran, le "équivalent" est à déclarer comme Réel(DP) A(:) dans le s/r (si, strictement parlant, il y a plusieurs paramètres qui bénéficient de passage du tableau de limites, et en déclarant explicitement avec les limites, mais ce serait une longue digression pour un autre jour).

Qui est, Fortran ne passe pas par la valeur, ni de "faire des copies" pour Args/Mannequin de vars. L'Un() de l'appel de la s/r est le "même" que celui qui est utilisé dans le s/r (bien sûr, dans le s/r, on peut faire une copie d'un() ou que ce soit, qui permettrait de réaliser des travaux supplémentaires/exigences en matière d'espace, mais c'est une autre question).

C'est pour cette raison principalement que l'Intention n'affectent pas directement la performance dans une grande mesure, même pour le grand tableau du Gra etc.

B) Concernant le "passage par Valeur" confusion: Bien que les diverses réponse ci-dessus confirment que l'utilisation d'Intention "n'est pas le passage par valeur", il peut être utile de clarifier la question.

Il peut être utile de modifier le libellé de "l'Intention est toujours de passer par référence". Ce n'est pas la même chose que "ne pas passer par valeur", et il est important de subtilité. Notamment, ne sont pas seulement les Intentions de "byRef", l'Intention peut EMPÊCHER le passage par valeur.

Bien qu'il y a des/beaucoup plus complexe (par exemple de plusieurs langages Fortran DLL, etc) où beaucoup de discussion supplémentaire est requis, pour la plupart partie de la "norme Fortran", les Arguments sont passés par la Réf. Une des manifestations de cette "Intention de subtilité" peut être vu dans une simple extension de "L'Glazer Gars", par exemple, que:

subroutine sub(i)
    integer, intent(in) :: i, j
    integer, value     :: iV, jV
    call sub2(i)
    call sub3(i, j, jV, iV)
end
subroutine sub2(i)
    implicit none
    integer i
    i = 7  ! This works since the "intent" information was lost.
end
subroutine sub3(i, j, jV, iV)
    implicit none
    integer, value, Intent(In)          :: i    ! This will work, since passed in byRef, but used locally as byVal
    integer, value, Intent(InOut)       :: j    ! This will FAIL, since ByVal/ByRef collision with calling s/r,
                                                ! ||Error: VALUE attribute conflicts with INTENT(INOUT) attribute at (1)|
    integer, value, Intent(InOut)       :: iV   ! This will FAIL, since ByVal/ByRef collision with calling s/r,
                                                ! ... in spite of "byVal" in calling s/r
                                                ! ||Error: VALUE attribute conflicts with INTENT(INOUT) attribute at (1)|
    integer, value, Intent(Out)         :: jV   ! This will FAIL, since ByVal/ByRef collision with calling s/r
                                                ! ... in spite of "byVal" in calling s/r
                                                ! ||Error: VALUE attribute conflicts with INTENT(OUT) attribute at (1)|
    jV = -7
    iV = 7
end

Qui est, quoi que ce soit avec une "Sortie" aspect doit être "byRef" (au moins dans les paramètres normaux), depuis l'appel de la s/r s'attend à "byRef". Ainsi, même si tous les s/r déclarer Args "Valeur", ils sont "byVal" seulement localement (à nouveau dans la configuration standard). Donc, toute tentative par le rapport s/r pour le retour d'un Arg qui est déclaré comme étant de Valeur avec toute sorte de Sortir de l'Intention, ÉCHOUE en raison de la "collision" de la en passant les styles.

Si elle doit être "Out" ou "InOut" et "Valeur", alors on ne peut pas utiliser l'Intention: ce qui est un peu plus que de dire simplement "il n'est pas le passage par valeur".

OriginalL'auteur DrOli