Juste une petite confirmation : si i est un entier et t est par exemple
un tableau d'entiers ou de flottants, une instruction du style
t[i++]++;
n'est pas indéterminée, n'est-ce pas ? Par exemple si i vaut
initialement 42, l'instruction ci-dessus incrémente d'une unité la
valeur de t[42] tout en passant à la case suivante du tableau t ie la
case 43. Je pose aussi la question car j'ai rarement lu ce genre
d'instruction dans du "vrai" code, peut-être n'est-ce pas considéré
comme très lisible, voire considéré comme source de trouble ou alors,
peut-être n'ai-je pas une fréquentation assez assidue du code "réel" ;)
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu. C'est pas pire que d'ecrire une longue expression arithmetique sans la decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible que certaines longues expressions flottantes que j'ai vues, qui sournoisement pouvaient faire des erreurs en plusieurs endroits, style debordement ou division par zero, si tu veux taper dans la semantique des effets de bords multiples...
In article <4ad1dcb3$0$1004$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4ad1bc1a$0$964$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et
source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois
pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu.
C'est pas pire que d'ecrire une longue expression arithmetique sans la
decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais
de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible
que certaines longues expressions flottantes que j'ai vues, qui sournoisement
pouvaient faire des erreurs en plusieurs endroits, style debordement ou
division par zero, si tu veux taper dans la semantique des effets de bords
multiples...
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu. C'est pas pire que d'ecrire une longue expression arithmetique sans la decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible que certaines longues expressions flottantes que j'ai vues, qui sournoisement pouvaient faire des erreurs en plusieurs endroits, style debordement ou division par zero, si tu veux taper dans la semantique des effets de bords multiples...
Wykaaa
Marc Espie a écrit :
In article <4ad1dcb3$0$1004$, Wykaaa wrote:
Marc Espie a écrit :
In article <4ad1bc1a$0$964$, Wykaaa wrote:
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu. C'est pas pire que d'ecrire une longue expression arithmetique sans la decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible que certaines longues expressions flottantes que j'ai vues, qui sournoisement pouvaient faire des erreurs en plusieurs endroits, style debordement ou division par zero, si tu veux taper dans la semantique des effets de bords multiples...
Ok. Les plus sournoises sont les expressions qui contiennent potentiellement des possibilités de débordement, surtout quand les optimiseurs réarrangent l'ordre des termes...
Marc Espie a écrit :
In article <4ad1dcb3$0$1004$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4ad1bc1a$0$964$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et
source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois
pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu.
C'est pas pire que d'ecrire une longue expression arithmetique sans la
decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais
de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible
que certaines longues expressions flottantes que j'ai vues, qui sournoisement
pouvaient faire des erreurs en plusieurs endroits, style debordement ou
division par zero, si tu veux taper dans la semantique des effets de bords
multiples...
Ok.
Les plus sournoises sont les expressions qui contiennent potentiellement
des possibilités de débordement, surtout quand les optimiseurs
réarrangent l'ordre des termes...
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Lisible certes, mais sémantiquement parlant ?
Oui. C'est juste une expression un peu longue. La comme ca, je ne vois pas d'algo ou ca pourrait servir, mais ca ne me semble pas tres tordu. C'est pas pire que d'ecrire une longue expression arithmetique sans la decouper en sous-morceaux.
La longueur d'une expression, c'est sa forme, sa syntaxe. Je te parlais de sémantique :-(
Ben moi ca me parle encore raisonnablement. Ca me parait meme moins terrible que certaines longues expressions flottantes que j'ai vues, qui sournoisement pouvaient faire des erreurs en plusieurs endroits, style debordement ou division par zero, si tu veux taper dans la semantique des effets de bords multiples...
Ok. Les plus sournoises sont les expressions qui contiennent potentiellement des possibilités de débordement, surtout quand les optimiseurs réarrangent l'ordre des termes...
Hamiral
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a éc rit ça pourrait faire pire...
Ham
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et
source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++;
i++;
La première forme est certes lisible, mais on sent que celui qui a éc rit
ça pourrait faire pire...
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a éc rit ça pourrait faire pire...
Ham
Samuel Devulder
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Pour rester dans l'écriture d'origine, on peut aussi l'écrire ainsi:
++t[i++]
ce qui correspond mieux au fait qu'on incrémente de 1 unité les éléments d'un tableaux tout en le parcourant sans se préoccuper de la valeur précédente de la case du tableau. Ca n'est pas si rare que cela. Une autre possibilité d'écriture est le ++(*t++), qui compte tenu des règles de priorité peut aussi s'écrire:
++*t++
Et là j'avoue que c'est du grand art digne de l'obfuscation!
#include <stdio.h>
int main(void) { static int buf[] = {1, 2, 3, 0}; int *t;
for(t = buf; *t; ++*t++);
for(t = buf; *t; ++t) printf("%d ", *t);
return 0; }
sam.
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et
source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++;
i++;
La première forme est certes lisible, mais on sent que celui qui a écrit
ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à
++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1,
lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire
++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est
plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo
fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche
de la sémantique de t[i++].
Pour rester dans l'écriture d'origine, on peut aussi l'écrire ainsi:
++t[i++]
ce qui correspond mieux au fait qu'on incrémente de 1 unité les éléments
d'un tableaux tout en le parcourant sans se préoccuper de la valeur
précédente de la case du tableau. Ca n'est pas si rare que cela. Une
autre possibilité d'écriture est le ++(*t++), qui compte tenu des règles
de priorité peut aussi s'écrire:
++*t++
Et là j'avoue que c'est du grand art digne de l'obfuscation!
#include <stdio.h>
int main(void) {
static int buf[] = {1, 2, 3, 0};
int *t;
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Pour rester dans l'écriture d'origine, on peut aussi l'écrire ainsi:
++t[i++]
ce qui correspond mieux au fait qu'on incrémente de 1 unité les éléments d'un tableaux tout en le parcourant sans se préoccuper de la valeur précédente de la case du tableau. Ca n'est pas si rare que cela. Une autre possibilité d'écriture est le ++(*t++), qui compte tenu des règles de priorité peut aussi s'écrire:
++*t++
Et là j'avoue que c'est du grand art digne de l'obfuscation!
#include <stdio.h>
int main(void) { static int buf[] = {1, 2, 3, 0}; int *t;
for(t = buf; *t; ++*t++);
for(t = buf; *t; ++t) printf("%d ", *t);
return 0; }
sam.
Hamiral
Samuel Devulder a écrit :
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langa ge et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le comp ilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Raison de plus pour écrire les deux instructions, dans l'ordre, sur deu x lignes de code séparées. Ça évite bien des bugs et des erreurs de lecture.
Ham
Samuel Devulder a écrit :
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langa ge
et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++;
i++;
La première forme est certes lisible, mais on sent que celui qui a
écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à
++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1,
lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire
++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est
plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le comp ilo
fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche
de la sémantique de t[i++].
Raison de plus pour écrire les deux instructions, dans l'ordre, sur deu x
lignes de code séparées. Ça évite bien des bugs et des erreurs de lecture.
Typiquement du code qui ne devrait être autorisé par aucun langa ge et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le comp ilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Raison de plus pour écrire les deux instructions, dans l'ordre, sur deu x lignes de code séparées. Ça évite bien des bugs et des erreurs de lecture.
Ham
espie
In article <4ad34af6$0$24670$, Samuel Devulder wrote:
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca donne le meme resultat, et c'est traditionnel d'ecrire i++.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons d'efficacite pour les classes definies par l'utilisateur.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de vue.
Apres, si dans tes autres exemples, tu veux montrer que la difference est subtile entre des constructions tres comprehensibles et des machins illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
In article <4ad34af6$0$24670$426a74cc@news.free.fr>,
Samuel Devulder <samuel-dot-devulder@geensys.com> wrote:
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et
source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++;
i++;
La première forme est certes lisible, mais on sent que celui qui a écrit
ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à
++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1,
lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire
++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est
plus clair.
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca
donne le meme resultat, et c'est traditionnel d'ecrire i++.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons
d'efficacite pour les classes definies par l'utilisateur.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo
fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche
de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de
vue.
Apres, si dans tes autres exemples, tu veux montrer que la difference
est subtile entre des constructions tres comprehensibles et des machins
illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci
avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les
regles de base du langage. S'il a des problemes avec, il peut retourner
faire du java ou du pascal...
In article <4ad34af6$0$24670$, Samuel Devulder wrote:
Hamiral a écrit :
Marc Espie a écrit :
In article <4ad18dbe$0$993$, Wykaaa wrote:
Typiquement du code qui ne devrait être autorisé par aucun langage et source de confusion.
Tu exageres, c'est quand meme tres lisible quand on connait C...
Franchement, moi, je ne vois pas l'intérêt par rapport à
t[i]++; i++;
La première forme est certes lisible, mais on sent que celui qui a écrit ça pourrait faire pire...
Bien souvent les gens écrivent i++ alors qu'ils pensent en réalité à ++i. En effet, veulent faire i = i + 1, ce qui est équivalent à i += 1, lui même équivalent à ++i. Du coup perso j'ai plutôt tendance à écrire ++i dans les boucles et autres endroit où je veux faire i = i + 1. C'est plus clair.
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca donne le meme resultat, et c'est traditionnel d'ecrire i++.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons d'efficacite pour les classes definies par l'utilisateur.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de vue.
Apres, si dans tes autres exemples, tu veux montrer que la difference est subtile entre des constructions tres comprehensibles et des machins illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
Hamiral
Marc Espie a écrit :
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Ham
Marc Espie a écrit :
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci
avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les
regles de base du langage. S'il a des problemes avec, il peut retourner
faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Ham
espie
In article <4ad36afd$0$2106$, Hamiral wrote:
Marc Espie a écrit :
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Ham
C'est une moitie de blague. Je rencontre plus de programmeurs incompetents dans un langage que dans l'autre...
In article <4ad36afd$0$2106$426a74cc@news.free.fr>,
Hamiral <hamiral@hamham.com> wrote:
Marc Espie a écrit :
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci
avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les
regles de base du langage. S'il a des problemes avec, il peut retourner
faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Ham
C'est une moitie de blague. Je rencontre plus de programmeurs incompetents
dans un langage que dans l'autre...
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
C'est une blague ? On peut faire la même chose en java...
Ham
C'est une moitie de blague. Je rencontre plus de programmeurs incompetents dans un langage que dans l'autre...
Samuel Devulder
Marc Espie a écrit :
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca
Les gens? Beaucoup de monde en réalité. 95% des gens que je croise utilisent i++ par (mauvaise) habitude. J'ai rien contre si c'est une habitude assumée comme tel, par contre il faut dire vite que ça n'a pas d'importance... car c'est fondamentalement faux. Les expressions ++i et i++ ne sont pas équivalentes.
donne le meme resultat, et c'est traditionnel d'ecrire i++.
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat". Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3; int j = i++; /* j vaut 3 */ int k = ++i; /* k vaut 5 */
par contre '++' avant ou après le i donne le même résultat sur la variable i une fois l'instruction executée: elle a été incrémentée d'une unité.
Je trouve que considérer que i++ est identique à ++i introduit une légère confusion dans la tête du programmeur dont certains te soutiennent après quelque temps de codage "par automatisme, sans réfléchir" que le ++ peut être mis avant ou après sans que ça change rien, ce qui est un mauvais réflexe.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons d'efficacite pour les classes definies par l'utilisateur.
Pas que C++, en C aussi.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de vue.
Bah on peut aussi écrire à la pascal/ada et interdire l'usage des opérateurs à effets de bords '++' et '--' (et les +=, -= et autre <<= pendant qu'on y est :) ). Chacun fait ce qu'il veut.
Apres, si dans tes autres exemples, tu veux montrer que la difference est subtile entre des constructions tres comprehensibles et des machins illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
En effet.. Mais perso je considère que quelqu'un qui écrit i++ en lieu et place de ++i pas par habitude mais en étant persuadé que les deux expressions sont équivalentes à i+=1 est quelqu'un qui ne connaît pas assez le C (peut-être code t'il trop par automatisme). Seul ++i est équivalent à i+=1, lui même équivalent à (i=i+1).
sam (<==Amiga still running :) )
Marc Espie a écrit :
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca
Les gens? Beaucoup de monde en réalité. 95% des gens que je croise
utilisent i++ par (mauvaise) habitude. J'ai rien contre si c'est une
habitude assumée comme tel, par contre il faut dire vite que ça n'a pas
d'importance... car c'est fondamentalement faux. Les expressions ++i et
i++ ne sont pas équivalentes.
donne le meme resultat, et c'est traditionnel d'ecrire i++.
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat".
Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3;
int j = i++; /* j vaut 3 */
int k = ++i; /* k vaut 5 */
par contre '++' avant ou après le i donne le même résultat sur la
variable i une fois l'instruction executée: elle a été incrémentée d'une
unité.
Je trouve que considérer que i++ est identique à ++i introduit une
légère confusion dans la tête du programmeur dont certains te
soutiennent après quelque temps de codage "par automatisme, sans
réfléchir" que le ++ peut être mis avant ou après sans que ça change
rien, ce qui est un mauvais réflexe.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons
d'efficacite pour les classes definies par l'utilisateur.
Pas que C++, en C aussi.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo
fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche
de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de
vue.
Bah on peut aussi écrire à la pascal/ada et interdire l'usage des
opérateurs à effets de bords '++' et '--' (et les +=, -= et autre <<=
pendant qu'on y est :) ). Chacun fait ce qu'il veut.
Apres, si dans tes autres exemples, tu veux montrer que la difference
est subtile entre des constructions tres comprehensibles et des machins
illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci
avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les
regles de base du langage. S'il a des problemes avec, il peut retourner
faire du java ou du pascal...
En effet.. Mais perso je considère que quelqu'un qui écrit i++ en lieu
et place de ++i pas par habitude mais en étant persuadé que les deux
expressions sont équivalentes à i+=1 est quelqu'un qui ne connaît pas
assez le C (peut-être code t'il trop par automatisme). Seul ++i est
équivalent à i+=1, lui même équivalent à (i=i+1).
C'est qui "les gens" ? en C, ca n'a pas d'importance dans les cas ou ca
Les gens? Beaucoup de monde en réalité. 95% des gens que je croise utilisent i++ par (mauvaise) habitude. J'ai rien contre si c'est une habitude assumée comme tel, par contre il faut dire vite que ça n'a pas d'importance... car c'est fondamentalement faux. Les expressions ++i et i++ ne sont pas équivalentes.
donne le meme resultat, et c'est traditionnel d'ecrire i++.
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat". Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3; int j = i++; /* j vaut 3 */ int k = ++i; /* k vaut 5 */
par contre '++' avant ou après le i donne le même résultat sur la variable i une fois l'instruction executée: elle a été incrémentée d'une unité.
Je trouve que considérer que i++ est identique à ++i introduit une légère confusion dans la tête du programmeur dont certains te soutiennent après quelque temps de codage "par automatisme, sans réfléchir" que le ++ peut être mis avant ou après sans que ça change rien, ce qui est un mauvais réflexe.
il n'y a que en C++ qu'on prefere regulierement ++i pour des raisons d'efficacite pour les classes definies par l'utilisateur.
Pas que C++, en C aussi.
Du coup pourquoi ne pas écrire ++t[i]; ++i; en espérant que le compilo fusionne le t[i] et le ++i qui suit en l'instruction asm la plus proche de la sémantique de t[i++].
Ca change quoi ? c'est aussi lisible dans les deux cas, de mon point de vue.
Bah on peut aussi écrire à la pascal/ada et interdire l'usage des opérateurs à effets de bords '++' et '--' (et les +=, -= et autre <<= pendant qu'on y est :) ). Chacun fait ce qu'il veut.
Apres, si dans tes autres exemples, tu veux montrer que la difference est subtile entre des constructions tres comprehensibles et des machins illisibles... ben il suffit de le dire.
Quelqu'un qui sait programmer en C ne doit pas avoir le moindre souci avec notre t[i++]++ du debut. Faut quand meme pas deconner, c'est les regles de base du langage. S'il a des problemes avec, il peut retourner faire du java ou du pascal...
En effet.. Mais perso je considère que quelqu'un qui écrit i++ en lieu et place de ++i pas par habitude mais en étant persuadé que les deux expressions sont équivalentes à i+=1 est quelqu'un qui ne connaît pas assez le C (peut-être code t'il trop par automatisme). Seul ++i est équivalent à i+=1, lui même équivalent à (i=i+1).
sam (<==Amiga still running :) )
espie
In article <4ad3738c$0$3737$, Samuel Devulder wrote:
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat". Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3; int j = i++; /* j vaut 3 */ int k = ++i; /* k vaut 5 */
ce que j'appelle avoir le meme resultat, c'est avoir le meme comportement observable. Ce qui est le cas dans l'ecrasante majorite des utilisations de i++ (a savoir: for (i = 0; i < n; i++) et assimies).
sam (<==Amiga still running :) )
Bah, les miens fonctionnent encore, mais je ne m'en sers plus. Me suis meme jamais motive pour rajouter un disque et retrouver un systeme pour la tour 1200/060 qu'on m'avait file... ;(
In article <4ad3738c$0$3737$426a34cc@news.free.fr>,
Samuel Devulder <samuel-dot-devulder@geensys.com> wrote:
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat".
Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3;
int j = i++; /* j vaut 3 */
int k = ++i; /* k vaut 5 */
ce que j'appelle avoir le meme resultat, c'est avoir le meme comportement
observable. Ce qui est le cas dans l'ecrasante majorite des utilisations
de i++ (a savoir: for (i = 0; i < n; i++) et assimies).
sam (<==Amiga still running :) )
Bah, les miens fonctionnent encore, mais je ne m'en sers plus. Me suis meme
jamais motive pour rajouter un disque et retrouver un systeme pour la tour
1200/060 qu'on m'avait file... ;(
In article <4ad3738c$0$3737$, Samuel Devulder wrote:
Cela dépend du compilo et de ce qu'on appelle "avoir le même résultat". Pour moi ca ne donne pas le résultat (dans le cas général):
int i = 3; int j = i++; /* j vaut 3 */ int k = ++i; /* k vaut 5 */
ce que j'appelle avoir le meme resultat, c'est avoir le meme comportement observable. Ce qui est le cas dans l'ecrasante majorite des utilisations de i++ (a savoir: for (i = 0; i < n; i++) et assimies).
sam (<==Amiga still running :) )
Bah, les miens fonctionnent encore, mais je ne m'en sers plus. Me suis meme jamais motive pour rajouter un disque et retrouver un systeme pour la tour 1200/060 qu'on m'avait file... ;(
