Re: Ada.Text_IO

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 réponds donc à celle-ci, les autres plus tard:
Le 06/12/2021 à 16:25, Thomas De Contes a écrit :
>>> 2)
>>> Close
>>> 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, donc si on a un fichier local F, on devrait toujours avoir à la fin:
>> exception
>>    when others =>
>>       if Is_open (F) then
>>          Close (F);
>>       end if;
> Ok, j'ai corrigé tout ce que j'ai vu, merci:-)
> 
> 
> Pourquoi est-ce que c'était compliqué à corriger au moment de la création des types contrôlés ?
> Est-ce que ça impliquait des changements d'usage, jugés trop cher pour les "gros utilisateurs" ?
> Ou alors, pas de changement d'usage, mais des changements dans les compilateurs, jugés trop cher pour les fabricants de compilateurs ?
Les types contrôlés sont des types étiquetés, qui sont souvent banis des 
applis temps-réel/sécuritaires. 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à.
> 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...

> 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...

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52
https://www.adalog.fr
_______________________________________________
Ada-france mailing list
[email protected]
https://mail.ada-france.org/cgi-bin/mailman/listinfo/ada-france