grrr c koi cette erreur ? [ADA95] - Ada - Programmation
Marsh Posté le 02-09-2002 à 22:54:31
C'est quoi comme langage ça
Le truc d'Oracle ? (PLSQL?)
Marsh Posté le 02-09-2002 à 23:19:06
es-tu sûr que liste n'a pas été déclarée comme constante ?
Marsh Posté le 02-09-2002 à 23:22:37
et liste n'a pas ete declare comme une constante
vla mon code :
Code :
|
Marsh Posté le 02-09-2002 à 23:38:03
Je t'avoue que je ne suis plus vraiment dans l'Ada...
Mais à mon avis, l'idée pour commencer à debuger dans ta fonction image, est de voir si tu peux modifier liste avec une commande à la con.
Si c'est ça, c'est p-e une histoire de in/out qui couille sur liste
Marsh Posté le 02-09-2002 à 23:56:07
hehe bien joue man
g remplace par ca :
function image(list : LISTES) return string is
liste : LISTES := list;
et ca compile nickel
Marsh Posté le 03-09-2002 à 00:02:12
ok c cool, c ce que je pensais...
mais je ne savais plus si fallait un .all ou pas ??
Marsh Posté le 03-09-2002 à 00:04:26
swich a écrit a écrit : ouaip c de l'ada 95 |
ça aurait été bien de le mettre dans la section ADA et de l'indiquer dans le premier post
Bon vais le faire moi-même...
Marsh Posté le 03-09-2002 à 00:51:23
ben non pq des que je met qqchose ds la section ada, y'a jamais de reponse, dc la dsl mais ct important
Marsh Posté le 03-09-2002 à 09:58:40
si tu le mets dans la section ADA il apparaît dans la sous-section ADA et dans la section principale.
Si tu ne le mets dans aucune sous-section il n'apparaît que dans la section principale... donc tu as tout intérêt à utiliser ces sous-sections pour si jamais y a un gars qui vient juste voir les topics ADA.
Et si personne y répond c'est peut-être qu'il y a très peu de gens ici qui pourraient le faire
Marsh Posté le 03-09-2002 à 10:40:30
y a aussi le fait que tu réponds pas aux questions dans tes post : tu écris ton problème et tu te casses !
Marsh Posté le 03-09-2002 à 11:00:43
swich a écrit a écrit : ben non pq des que je met qqchose ds la section ada, y'a jamais de reponse, dc la dsl mais ct important |
J'ai juste une question qui me trote... Tu peux me rappeler le sens du .all pour un type liste ? Merci
Marsh Posté le 03-09-2002 à 13:23:59
swich a écrit a écrit : hehe bien joue man g remplace par ca : function image(list : LISTES) return string is liste : LISTES := list; et ca compile nickel |
C'est pas très malin de faire ça...
Globalement, dans une fonction ("image" ) qui promet de ne pas modifier "list", tu essaies d'appeler une procédure ("avancer" ) qui va la modifier.
Résultat, tu es obligé de faire une copie locale de ta liste !
Dans le genre efficace, on fait mieux...
Ou alors, dans le cas présent (si l'opérateur "=" n'est pas redéfini sur ton type LISTES), c'est pire : cette copie locale introduit probablement un bug, car a priori, si "avancer" attend un paramètre en in/out, c'est qu'il modifie cet objet...
Tu ferais mieux de réléchir un peu plus attentivement à qui doit modifier quoi, et écrire (enfin, modifier) ton code en conséquence...
Marsh Posté le 03-09-2002 à 13:28:04
ouaip ben en fait le prob c tout bete, c qu'il peut pas modifier liste pq il est en mode in, donc y fo faire une copie
Marsh Posté le 03-09-2002 à 13:32:54
chicha a écrit a écrit : J'ai juste une question qui me trote... Tu peux me rappeler le sens du .all pour un type liste ? Merci |
Pas pour un type liste, pour un type accès (bref, un pointeur). Cela permet de manipuler l'agrégat pointé dans son ensemble (la valeur de type record, si tu préfères).
En toute logique, pour accéder à n'importe quel des champs d'un agrégat pointé, il faudrait aussi utiliser " .all ". Exemple, "elem" est de type "access ELEMS" :
Code :
|
On "ouvre le pointeur pour accéder à l'agrégat pointé, avant d' "ouvrir" l'agrégat pour accéder à l'un de ses champs. Mais dans ce cas précis, Ada accepte que le " .all " soit implicite, et l'on peut écrire :
Code :
|
Marsh Posté le 03-09-2002 à 13:39:16
swich a écrit a écrit : ouaip ben en fait le prob c tout bete, c qu'il peut pas modifier liste pq il est en mode in, donc y fo faire une copie |
Non, le problème, c'est que tu utilises une procédure qui modifie "liste" dans une fonction qui ne la modifie pas. Alors soit "image" doit bien appeler "avancer", mais dans ce cas, le prototype d'"avancer" n'est pas correct, ou alors c'est "avancer" qui est correct, et dans ce cas c'est "image" qui ne doit pas appeler "avancer". Mais dupliquer les objets en mémoire parce que le compilateur interdit l'accès direct aux variables est une très mauvaise manière de résoudre les problèmes. Imagine que ta liste nécessite plusieurs dizaines ou centaines de mégaoctets en mémoire. Je ne te raconte pas l'état de ta machine au simple appel d'"image" (facile : sur les rotules... )
Marsh Posté le 04-09-2002 à 10:11:21
Ca s'appelle la programmation par interfaces.
Ca paraît un peu rigide comme raisonnement, mais quand on bosse à plusieurs, c'est la manière la plus efficace de bosser que je connaisse (on peut atteindre des rendements de folie en termes de production de code sans bug)... à condition évidemment de respecter le contrat défini par les interfaces qu'on s'était donné au préalable.
Marsh Posté le 02-09-2002 à 22:41:16
voila mon code :
et az la compilation g l'erreur :
actual for list must be a variable
Message édité par swich le 03-09-2002 à 00:04:41