Re: Ada.Text_IO - Close

Le 6 déc. 2021 à 18:56, Jean-Pierre Rosen a écrit :

> NB: il vaudrait mieux que tu ne poses qu'une seule question par message (mais autant de messages que tu veux, bien sûr). C'est plus facile pour répondre, ça fait des messages de taille raisonnable, et surtout ça facilite les recherches ultérieures pour ceux qui se poseraient la même question...

Je fais le découpage surtout en vue de faciliter les recherches ultérieures. Mais de la même façon, n'hésites pas à me dire autant que tu veux si ça n'est pas à ton gout. :-)


> 
> Je réponds donc à celle-ci, les autres plus tard:
> Le 06/12/2021 à 16:25, Thomas De Contes a écrit :

>>>> File_Type n'est pas un type contrôlé, donc quand c'est une variable locale il n'est pas finalisé au moment de sa disparition,
>>>> donc si on veut que ça soit fermé proprement, Close est obligatoire (notamment en cas d'exceptions).
>>>> Est-ce que ça a été conçu comme ça exprès ?
>>> Ca a été conçu avant l'existence des types contrôlés

>> Pourquoi est-ce que c'était compliqué à corriger au moment de la création des types contrôlés ?

> Les types contrôlés sont des types étiquetés, qui sont souvent banis des applis temps-réel/sécuritaires.

Ok, c'est surement pour le même genre de raison qu'il y a 3 versions des paquetages pour les conteneurs.

> Et puis soyons honnète, le modèle open/close est ancré dans les têtes depuis bien longtemps... et je ne me rappelle pas que quiconque ait demandé un changement de ce côté là.

Je n'ai rien contre le modèle open/close a priori :
Le problème est le cas où un programmeur étourdi ne fait pas le Close.
(Je viens de m'apercevoir d'un nouvel oubli alors que je pensais avoir tout vérifié.)

Si on veut obliger le programmeur à faire le Close, on peut décider qu'au moment où la variable disparait, au lieu de faire le Close automatiquement et silencieusement, on soulève une exception s'il n'a pas été fait.
Alors que là, à la place, ça fait des fuites de mémoire et des descripteurs de fichiers qui se baladent ...

Je ne sais pas bien comment mesurer si l'enjeu fait que ça vaut le coup ou pas, de modifier le langage et de faire un 2ème paquetage pour les applis temps-réel/sécuritaires.


>> Pourquoi est-ce que Close réclame que le fichier soit ouvert (et que, avec un fichier fermé, il ne se contente pas de ne rien faire, comme Ada.Unchecked_Deallocation avec les pointeurs nuls) ?
>> (Si la raison est uniquement historique : même question sur le changement du langage.)
> Honnètement, je ne sais pas. Je pense qu'Ichbiah estimait qu'on doit toujours connaître l'état de ses fichiers, et donc qu'un Close d'un fichier fermé était une erreur. A ce niveau, c'est une question de philosophie personnelle...

C'est vrai qu'a priori, il n'y a que dans le traitement d'exception que ça alourdit.

Si on va par là, on pourrait décider pour aider au debuggage que Ada.Unchecked_Deallocation ne doit être appelé que quand il y a effectivement de la mémoire à désallouer.
(Est-ce que cette discussion a déjà eu lieu ?)


> 
>> Il se trouve que je vais avoir besoin de mettre un Ada.Text_IO.File_Type dans un type composé plus gros.
>> Est-ce que c'est bien, puisque j'en ai l'occasion (je ne le fais pas exprès pour ça), d'en faire un type contrôlé, d'appeler Close automatiquement à la fin, et de ne même pas le proposer comme primitive puisque c'est inutile ?
>> Ou bien est-ce que c'est une mauvaise pratique, et il vaut beaucoup mieux reproduire le comportement de Ada.Text_IO.File_Type à travers le type englobant ?
> Si le fichier est caché (type privé), alors ça demande certainement une gestion automatique. Menfin ne cherche pas trop de règles absolues, à ce niveau ça devient personnel...

Je pense que je vais conserver le modèle open/close, et en profiter pour mettre un traitement différent en cas d'exception, en économisant le traitement d'exception chez les appelants (mais pas le Close).


-- 
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france