Sujet : changer de sous-type au surnommage
De : fantome.forums.tDeContes (at) *nospam* free.fr.invalid (Thomas)
Groupes : fr.comp.lang.adaDate : 19. Jan 2022, 22:24:15
Autres entêtes
Organisation : Guest of ProXad - France
Message-ID : <fantome.forums.tDeContes-6D7E27.22241519012022@news.free.fr>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
User-Agent : MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
In article <
ss8bkv$hsu$1@dont-email.me>, "J-P. Rosen" <
rosen@adalog.fr>
wrote:
Le 19/01/2022 à 04:23, Thomas a écrit :
2) Le /type/ donné dans un rename doit correspondre au /type/ de ce qui
est renommé (on devrait dire surnommé en bon français). En revanche, il
n'y a pas de vérification que les /sous-types/ correspondent, donc pas
de Constraint_Error si la valeur surnommée n'est pas dans l'intervalle
du sous-type annoncé dans le rename.
si je te comprend bien,
- il n'y a pas d'outre-passement de (donc il y a) vérification du
sous-type du résultat de la fonction,
- mais il n'y a pas de vérification du sous-type annoncé dans le rename ?
c'est dommage,
Le problème (surtout en Ada 83 d'où provient la règle), c'est qu'un
sous-type peut être dynamique,
en Ada 83 un sous-type pouvait déjà être dynamique ?
et une règle de compilation ne peut pas
dépendre de quelque chose qui n'est connu qu'à l'exécution.
je ne comprend pas ce que tu dis, puisque le comportement attendu est de
lever Constraint_Error à l'exécution.
A partir d'Ada 95, on a introduit la notion de "statically matching
subtypes", mais il a été estimé que cela compliquerait trop les choses
de l'appliquer aux rename,
(peut-être que je comprendrai avec les questions précédentes)
et de toute façon ça ne pouvait pas marcher
dans tous les cas sans casser la compatibilité.
le 2eme argument tout seul est insuffisant, puisqu'une compatibilité
imparfaite est pratiquée quand il est estimé qu'elle vaut le coup.
mais je ne visualise pas du tout, même pas en ordre de grandeur, ce que
ça peut couter aux uns ou aux autres, de modifier telle ou telle chose.
de même que l'interdiction du mot "constant", qui ne devrait pas
forcément vérifier si l'objet pointé en est une, mais au moins que toute
utilisation du surnom respecte ça.
Ca c'est fait:
procedure Essai is
V : constant Integer := 0;
C : Integer renames V;
begin
C:= 3; -- left hand side of assignment must be a variable
end Essai;
veux tu dire qu'avant on n'avait pas le droit de surnommer une constante
?
ce dont je parlais c'était plutôt ça :
V : Integer := 0;
C : constant Integer renames V;
d'après mon expérience, c'est totalement interdit d'écrire ça,
et d'après ce que j'ai compris du langage, c'est autorisé mais sans
aucune conséquence (c'est pire).
en fait, ce qui me paraitrait logique, c'est que :
- le surnom doive obligatoirement être marqué "constant" si l'objet
pointé l'est, mais pas réciproquement,
- l'usage autorisé du surnom dépende du marquage du surnom, pas de
l'objet pointé.
PS : j'espère que tu m'excuses pour les majuscules,
mon client "news" n'a pas de fonction pour mettre des majuscules
automatiquement (contrairement à mon client courriel),
et je trouve ça vraiment trop fastidieux de devoir penser à la touche
majuscule en même temps qu'écrire et chercher la bonne lettre sur le
clavier.
-- RAPID maintainerhttp://savannah.nongnu.org/projects/rapid/