J'ai une petite question : si a est un vecteur et f une fonction, est-ce que "let b= f a", lorsque f est l'identité, permet de créer un vecteur b indépendant de a, ou est-ce qu'il faut écrire "let b= copy_vect (f a)" ?
J'ai une petite question : si a est un vecteur et f une fonction, est-ce que "let b= f a", lorsque f est l'identité, permet de créer un vecteur b indépendant de a, ou est-ce qu'il faut écrire "let b= copy_vect (f a)" ?
Salut !
Le test est très facile à faire :J'ai une petite question : si a est un vecteur et f une fonction, est-ce que "let b= f a", lorsque f est l'identité, permet de créer un vecteur b indépendant de a, ou est-ce qu'il faut écrire "let b= copy_vect (f a)" ?
Il suffit de comparer le résultat de testf (fun x -> x) (= true) et testf Array.copy (= false). Donc la réponse est non. L'identité est une identité, pas une copie ! Il faut utiliser Array.copy (vect_copy avec caml-light) pour le faire.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6 let testf f = let x = [| 1; 2; 3 |] in let y = f x in y.(0) <- 2; x = y
Cordialement,
Cacophrène
Salut !
Une règle simple à appliquer quand on utilise les tableaux :Envoyé par elishac
(1) si on veut faire des effets de bord, c.-à-d. modifier le contenu des cases du tableau sur place, on ne fait pas de copie. Dans ce cas, la fonction renvoie généralement unit. (2) Si on veut coder sans effets de bord, c.-à-d. renvoyer un nouveau tableau, on crée une copie (copy_vect ou Array.copy) locale avant toute modification. C'est généralement cette copie qui est renvoyée comme résultat de la fonction.
À toi de voir ce que tu veux faire de ta fonction inverse_pol. Remarque : on a le choix parce que caml est un langage fonctionnel impur. Ceci dit, il faut se méfier des effets de bord et il n'est donc généralement pas recommandé d'en faire, sauf si c'est justifié (par exemple, recopier des tableaux de très grande taille peut être pénalisant ou rhédibitoire). Anti-remarque : les tableaux ont été implémentés comme modifiables sur place (mutable)...
A priori le recours massif aux traits impératifs indique qu'il y a matière à réécrire le code d'une façon plus idiomatique. D'ailleurs, les codes qui contiennent des boucles for et surtout while sont généralement plus difficiles à prouver, quand c'est demandé (recherche d'un invariant de boucle et tout ce qui s'ensuit).Envoyé par elishac
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager