Re: function ... return <objet li mité>;

Le 25 oct. 07 à 16:47, Jean-Pierre Rosen a écrit :

> Thomas De Contes a écrit :
>> D'après les messages d'erreur que j'ai, je crois deviner que
>> - en ada 95, on avait le droit de faire une fonction qui renvoie  
>> un  objet limité,
>> - en ada 2005, on n'a plus le droit
> Effectivement. Le problème est qu'en Ada 95, on était obligé de  
> faire des acrobaties pas possibles: normalement une fonction  
> renvoie une *valeur*, or on ne peut pas copier une valeur limitée.

des acrobaties, tu veux dire au niveau du compilateur ?


> Il y avait donc un cas particulier pour les types limités, où les  
> fonctions renvoyaient de façon cachée une référence sur la valeur:  
> c'était les "by reference types".

(c'était que pour les types limités ? c'était pas aussi pour des  
choses comme les gros record ?)

> Avec la généralisation des accès anonymes en Ada2005, on a préféré  
> dire la vérité. Donc il faut remplacer:
>    function F return Lim;
> par
>    function F return access Lim;
>
> En pratique, ça fait la même chose, mais l'utilisateur est au  
> courant (et doit gérer) le fait qu'on retourne une référence.

Personnellement, je préférais largement ce que proposait Ada 95,  
parce que


Je me suis donné comme règle de programmation de ne jamais utiliser  
de pointeurs dans la partie publique des paquetages
J'ai tjr peur de me retrouver avec un pointeur non nul qui pointe sur  
un espace désalloué (je suppose que la nouveauté "not null" ne règle  
pas le pb) suite à une mauvaise utilisation du paquetage
(alors que si ça reste à l'intérieur, une fois que le paquetage est  
bien ficelé, on est sur de pas avoir de pb quelle que soit son  
utilisation)

Alors que si le compilateur fait bien son travail, c'est sans aucun  
danger même si il utilise des pointeurs "par en dessous", non ?


D'ailleurs, on peut tjr utiliser des types limités dans des  
paramètres de n'importe quel mode (in/in out), et c'est bien des  
pointeurs qui sont utilisés aussi dans ce cas là, non ?

En fait, j'aurais tendance à dire "tant pis si ça donne du travail au  
compilateur, il est là pour ça", son but c'est de simplifier la tache  
du programmeur en vérifiant tout ce qui est droit de modifier, droit  
d'affectation, etc ...


Et ce changement, avec cette interdiction, m'ennuient un peu, parce  
que j'avais fait un paquetage pour "enrober" les types limités, pour  
pouvoir les manipuler plus facilement :

generic
	type objetLimite is limited private;
package objetNonLimites is
	type objetNonLimite is private;
	function contenu (onl : objetNonLimite) return objetLimite;
private
	type objetNonLimite is record
		p : access objetLimite;
	end record;
end objetNonLimites;

(j'ai raccourci la structure de données)

Et j'avais donc fait une fonction pour accéder à objetLimite à  
l'intérieur de objetNonLimite,
pas pour le copier bien sur :-) ,
mais on peut tjr avoir besoin d'accéder à une propriété ... accéder à  
la valeur d'un champ si c'est un limited record, ... voire le mettre  
dans un paramètre "in" !


Tant pis, je met de coté pour l'instant, et le jour où j'en aurai  
besoin je trouverais bien qqch ... peut être une procédure générique :-)


>
>> Pourquoi le compilateur ne fait une erreur que quand il voit   
>> l'instruction return à la fin du corps ?
>> Pourquoi il n'en fait pas des qu'il voit la spécification de la   
>> fonction ?
> Faudrait nous donner le source et les messages d'erreur...

pas la peine :-)
http://www.adacore.com/2007/09/24/ada-gem-10/
(merci Jérôme Haguet :-) )

Donc en fait, on a tjr le droit de faire des fonctions qui renvoient  
un objet limité, mais on n'a pas le droit d'écrire les mêmes choses  
dedans


D'ailleurs (encore), je viens de penser,
si ça se trouve, la restriction dont on parle plus haut a été faite  
(aussi) parce que c'était incompatible avec cette nouvelle forme,  
"return statement" (?)



J'espère que c'était pas trop confus :-)


-- 
j'agis contre l'assistanat, je travaille dans une SCOP !


_______________________________________________
Site WWW de l'association Ada-France: http://www.ada-france.org/
[email protected]
http://www.ada-france.org/mailman/listinfo/ada-france