Decalages d'un nombre de bits pouvant etre >= a la taille du type
134 réponses
Vincent Lefevre
J'ai besoin de faire un décalage vers la droite sur un type entier
(disons non signé) générique (i.e. défini par typedef) d'un certain
nombre constant de bits. Le problème est que ce nombre de bits peut
être supérieur ou égal à la taille du type en question. Une idée
sur la façon de faire ça efficacement sans obtenir de comportement
indéfini et sans passer par un outil du style "configure"?
| Dans l'article , | James Kanze écrit: | | > Gabriel Dos Reis writes: | | > |> Une optimisation ne change pas le fonctionnement observable. | | > Une optimisation peut très bien changer le fonctionnement observable, | > dans la mésure que le nouveau fonctionnement est aussi conforme. | | et également quand il y a du comportement indéfini (comme lire une | variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas d'optimisation.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m2hdp52eoz.fsf@lns-p19-1-82-251-74-192.adsl.proxad.net>,
| James Kanze <kanze@gabi-soft.fr> écrit:
|
| > Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > |> Une optimisation ne change pas le fonctionnement observable.
|
| > Une optimisation peut très bien changer le fonctionnement observable,
| > dans la mésure que le nouveau fonctionnement est aussi conforme.
|
| et également quand il y a du comportement indéfini (comme lire une
| variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas
d'optimisation.
| Dans l'article , | James Kanze écrit: | | > Gabriel Dos Reis writes: | | > |> Une optimisation ne change pas le fonctionnement observable. | | > Une optimisation peut très bien changer le fonctionnement observable, | > dans la mésure que le nouveau fonctionnement est aussi conforme. | | et également quand il y a du comportement indéfini (comme lire une | variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas d'optimisation.
-- Gaby
Jean-Marc Bourguet
Vincent Lefevre <vincent+ writes:
Dans l'article <ck6hsv$e0i$, Antoine Leca écrit:
En 20041008164722$, Vincent Lefevre va escriure:
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
int test(void) { return 1.1 + 2.0; }
Je comprend que tout comportement indéfini résultant de cette opération ne peut être observable que si test est exécuté.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <ck6hsv$e0i$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.gov> écrit:
En 20041008164722$5b80@vinc17.org, Vincent Lefevre va escriure:
et de ne considérer que l'expression constante 1 / 0 à évaluer à
la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 +
2.0 ne doit pas être évalué à la traduction, parce qu'on
saute le lien de causalité (en effet, rien ne dit a priori
si test() va être exécuté dans le programme). C'est bien
ça?
int test(void)
{
return 1.1 + 2.0;
}
Je comprend que tout comportement indéfini résultant de
cette opération ne peut être observable que si test est
exécuté.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
et de ne considérer que l'expression constante 1 / 0 à évaluer à la traduction
Non. Tu sautes le lien de causalité (les points de séquence).
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
int test(void) { return 1.1 + 2.0; }
Je comprend que tout comportement indéfini résultant de cette opération ne peut être observable que si test est exécuté.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article <ck6hsv$e0i$, | Antoine Leca écrit: | | > En 20041008164722$, Vincent Lefevre va escriure: | | > > et de ne considérer que l'expression constante 1 / 0 à évaluer à | > > la traduction | | > Non. Tu sautes le lien de causalité (les points de séquence). | | Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne | doit pas être évalué à la traduction, parce qu'on saute le lien | de causalité (en effet, rien ne dit a priori si test() va être | exécuté dans le programme). C'est bien ça?
Non.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <ck6hsv$e0i$1@shakotay.alphanet.ch>,
| Antoine Leca <root@localhost.gov> écrit:
|
| > En 20041008164722$5b80@vinc17.org, Vincent Lefevre va escriure:
|
| > > et de ne considérer que l'expression constante 1 / 0 à évaluer à
| > > la traduction
|
| > Non. Tu sautes le lien de causalité (les points de séquence).
|
| Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne
| doit pas être évalué à la traduction, parce qu'on saute le lien
| de causalité (en effet, rien ne dit a priori si test() va être
| exécuté dans le programme). C'est bien ça?
| Dans l'article <ck6hsv$e0i$, | Antoine Leca écrit: | | > En 20041008164722$, Vincent Lefevre va escriure: | | > > et de ne considérer que l'expression constante 1 / 0 à évaluer à | > > la traduction | | > Non. Tu sautes le lien de causalité (les points de séquence). | | Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne | doit pas être évalué à la traduction, parce qu'on saute le lien | de causalité (en effet, rien ne dit a priori si test() va être | exécuté dans le programme). C'est bien ça?
Non.
-- Gaby
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Si la machine abstraite ne l'évalue pas, alors tu ne peux pas l'observer.
Si ce n'est pas la machine abstraite qui l'évalue, qu'est-ce qui l'évalue?
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
int test(void) { return 1.1 + 2.0; }
Je comprend que tout comportement indéfini résultant de cette opération ne peut être observable que si test est exécuté.
Où est-ce que tu vois un comportement indéfini ici???
Dans l'article <87llegngki.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
Donc tu dis que dans le bout de programme suivant, 1.1 +
2.0 ne doit pas être évalué à la traduction, parce qu'on
saute le lien de causalité (en effet, rien ne dit a priori
si test() va être exécuté dans le programme). C'est bien
ça?
int test(void)
{
return 1.1 + 2.0;
}
Je comprend que tout comportement indéfini résultant de
cette opération ne peut être observable que si test est
exécuté.
Où est-ce que tu vois un comportement indéfini ici???
Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne doit pas être évalué à la traduction, parce qu'on saute le lien de causalité (en effet, rien ne dit a priori si test() va être exécuté dans le programme). C'est bien ça?
int test(void) { return 1.1 + 2.0; }
Je comprend que tout comportement indéfini résultant de cette opération ne peut être observable que si test est exécuté.
Où est-ce que tu vois un comportement indéfini ici???
| Dans l'article <ck6hsv$e0i$, | Antoine Leca écrit: | | > En 20041008164722$, Vincent Lefevre va escriure: | | > > et de ne considérer que l'expression constante 1 / 0 à évaluer à | > > la traduction | | > Non. Tu sautes le lien de causalité (les points de séquence). | | Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne | doit pas être évalué à la traduction, parce qu'on saute le lien | de causalité (en effet, rien ne dit a priori si test() va être | exécuté dans le programme). C'est bien ça?
Dans l'article <m3ekk8nesf.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <ck6hsv$e0i$1@shakotay.alphanet.ch>,
| Antoine Leca <root@localhost.gov> écrit:
|
| > En 20041008164722$5b80@vinc17.org, Vincent Lefevre va escriure:
|
| > > et de ne considérer que l'expression constante 1 / 0 à évaluer à
| > > la traduction
|
| > Non. Tu sautes le lien de causalité (les points de séquence).
|
| Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne
| doit pas être évalué à la traduction, parce qu'on saute le lien
| de causalité (en effet, rien ne dit a priori si test() va être
| exécuté dans le programme). C'est bien ça?
| Dans l'article <ck6hsv$e0i$, | Antoine Leca écrit: | | > En 20041008164722$, Vincent Lefevre va escriure: | | > > et de ne considérer que l'expression constante 1 / 0 à évaluer à | > > la traduction | | > Non. Tu sautes le lien de causalité (les points de séquence). | | Donc tu dis que dans le bout de programme suivant, 1.1 + 2.0 ne | doit pas être évalué à la traduction, parce qu'on saute le lien | de causalité (en effet, rien ne dit a priori si test() va être | exécuté dans le programme). C'est bien ça?
| Dans l'article , | James Kanze écrit: | | > Gabriel Dos Reis writes: | | > |> Une optimisation ne change pas le fonctionnement observable. | | > Une optimisation peut très bien changer le fonctionnement observable, | > dans la mésure que le nouveau fonctionnement est aussi conforme. | | et également quand il y a du comportement indéfini (comme lire une | variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas d'optimisation.
Les compilo optimisent indépendamment du fait qu'un programme a un comportement indéfini ou pas.
Dans l'article <m3mzywnhrh.fsf@merlin.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m2hdp52eoz.fsf@lns-p19-1-82-251-74-192.adsl.proxad.net>,
| James Kanze <kanze@gabi-soft.fr> écrit:
|
| > Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|
| > |> Une optimisation ne change pas le fonctionnement observable.
|
| > Une optimisation peut très bien changer le fonctionnement observable,
| > dans la mésure que le nouveau fonctionnement est aussi conforme.
|
| et également quand il y a du comportement indéfini (comme lire une
| variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas
d'optimisation.
Les compilo optimisent indépendamment du fait qu'un programme a un
comportement indéfini ou pas.
| Dans l'article , | James Kanze écrit: | | > Gabriel Dos Reis writes: | | > |> Une optimisation ne change pas le fonctionnement observable. | | > Une optimisation peut très bien changer le fonctionnement observable, | > dans la mésure que le nouveau fonctionnement est aussi conforme. | | et également quand il y a du comportement indéfini (comme lire une | variable non initialisée).
Si le program a un comportement indéfini, on ne parle pas d'optimisation.
Les compilo optimisent indépendamment du fait qu'un programme a un comportement indéfini ou pas.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Si la machine abstraite ne l'évalue pas, alors tu ne peux pas | > l'observer. | | Si ce n'est pas la machine abstraite qui l'évalue, qu'est-ce qui | l'évalue?
Ce thread montre qu'il n'y a que toi qui l'évalues :-)
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3vfdknhwn.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Si la machine abstraite ne l'évalue pas, alors tu ne peux pas
| > l'observer.
|
| Si ce n'est pas la machine abstraite qui l'évalue, qu'est-ce qui
| l'évalue?
Ce thread montre qu'il n'y a que toi qui l'évalues :-)
| Dans l'article , | Gabriel Dos Reis écrit: | | > Si la machine abstraite ne l'évalue pas, alors tu ne peux pas | > l'observer. | | Si ce n'est pas la machine abstraite qui l'évalue, qu'est-ce qui | l'évalue?
Ce thread montre qu'il n'y a que toi qui l'évalues :-)
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Jean-Marc Bourguet écrit: | | > Vincent Lefevre <vincent+ writes: | | > > Donc tu dis que dans le bout de programme suivant, 1.1 + | > > 2.0 ne doit pas être évalué à la traduction, parce qu'on | > > saute le lien de causalité (en effet, rien ne dit a priori | > > si test() va être exécuté dans le programme). C'est bien | > > ça? | > > | > > int test(void) | > > { | > > return 1.1 + 2.0; | > > } | | > Je comprend que tout comportement indéfini résultant de | > cette opération ne peut être observable que si test est | > exécuté. | | Où est-ce que tu vois un comportement indéfini ici???
Hello ?
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <87llegngki.fsf@news.bourguet.org>,
| Jean-Marc Bourguet <jm@bourguet.org> écrit:
|
| > Vincent Lefevre <vincent+news@vinc17.org> writes:
|
| > > Donc tu dis que dans le bout de programme suivant, 1.1 +
| > > 2.0 ne doit pas être évalué à la traduction, parce qu'on
| > > saute le lien de causalité (en effet, rien ne dit a priori
| > > si test() va être exécuté dans le programme). C'est bien
| > > ça?
| > >
| > > int test(void)
| > > {
| > > return 1.1 + 2.0;
| > > }
|
| > Je comprend que tout comportement indéfini résultant de
| > cette opération ne peut être observable que si test est
| > exécuté.
|
| Où est-ce que tu vois un comportement indéfini ici???
| Dans l'article , | Jean-Marc Bourguet écrit: | | > Vincent Lefevre <vincent+ writes: | | > > Donc tu dis que dans le bout de programme suivant, 1.1 + | > > 2.0 ne doit pas être évalué à la traduction, parce qu'on | > > saute le lien de causalité (en effet, rien ne dit a priori | > > si test() va être exécuté dans le programme). C'est bien | > > ça? | > > | > > int test(void) | > > { | > > return 1.1 + 2.0; | > > } | | > Je comprend que tout comportement indéfini résultant de | > cette opération ne peut être observable que si test est | > exécuté. | | Où est-ce que tu vois un comportement indéfini ici???
Hello ?
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | Dans l'article , | > | James Kanze écrit: | > | | > | > Gabriel Dos Reis writes: | > | | > | > |> Une optimisation ne change pas le fonctionnement observable. | > | | > | > Une optimisation peut très bien changer le fonctionnement observable, | > | > dans la mésure que le nouveau fonctionnement est aussi conforme. | > | | > | et également quand il y a du comportement indéfini (comme lire une | > | variable non initialisée). | | > Si le program a un comportement indéfini, on ne parle pas | > d'optimisation. | | Les compilo optimisent indépendamment du fait qu'un programme a un | comportement indéfini ou pas.
Qu'appelles-tu optimisation lorsques tu fais abstraction de la sémantique d'un programme ?
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3mzywnhrh.fsf@merlin.cs.tamu.edu>,
| Gabriel Dos Reis <gdr@cs.tamu.edu> écrit:
|
| > Vincent Lefevre <vincent+news@vinc17.org> writes:
|
| > | Dans l'article <m2hdp52eoz.fsf@lns-p19-1-82-251-74-192.adsl.proxad.net>,
| > | James Kanze <kanze@gabi-soft.fr> écrit:
| > |
| > | > Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
| > |
| > | > |> Une optimisation ne change pas le fonctionnement observable.
| > |
| > | > Une optimisation peut très bien changer le fonctionnement observable,
| > | > dans la mésure que le nouveau fonctionnement est aussi conforme.
| > |
| > | et également quand il y a du comportement indéfini (comme lire une
| > | variable non initialisée).
|
| > Si le program a un comportement indéfini, on ne parle pas
| > d'optimisation.
|
| Les compilo optimisent indépendamment du fait qu'un programme a un
| comportement indéfini ou pas.
Qu'appelles-tu optimisation lorsques tu fais abstraction de la
sémantique d'un programme ?
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | | > | Dans l'article , | > | James Kanze écrit: | > | | > | > Gabriel Dos Reis writes: | > | | > | > |> Une optimisation ne change pas le fonctionnement observable. | > | | > | > Une optimisation peut très bien changer le fonctionnement observable, | > | > dans la mésure que le nouveau fonctionnement est aussi conforme. | > | | > | et également quand il y a du comportement indéfini (comme lire une | > | variable non initialisée). | | > Si le program a un comportement indéfini, on ne parle pas | > d'optimisation. | | Les compilo optimisent indépendamment du fait qu'un programme a un | comportement indéfini ou pas.
Qu'appelles-tu optimisation lorsques tu fais abstraction de la sémantique d'un programme ?
