coder en ANSI veut dire respecter la norme et ne pas faire de suppositions sur les comportements indéfinis de la norme.
Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
CQFD.
On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.
Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.
[^] # Re: Bonne nouvelle
Posté par TImaniac (site web personnel) . En réponse à la dépêche Que penser du rachat de Novell ?. Évalué à 3.
Si tu veux utiliser des int, va pourtant bien falloir que tu fasses une supposition sur le comportement du compilateur... Si tu ne veux pas faire de supposition, la seule alternative qu'il te reste, c'est de ne pas utiliser le type int.
Tu peux aussi t'amuser à faire des tests à coup de #ifdef : pour que ton code deviennt "portable" : c'est jamais qu'un aveu de non portabilité : tu écris du code spécifiques dans chaque branche de ton if.
Les comportement indéfinis sont précisément là pour laisser champ libre à l’implémentation en fonction de l’architecture cible.
On est d'accord, y'a une bonne raison : c'est pour des questions de perf/optimisation. Mais il n'en reste pas moins que le code devient non portable puisqu'avec un comportement potentiellement différent d'une architecture à l'autre.
D'ailleur la phrase que tu cites est effectivement éloquente : grosso modo il est de la responsabilité du programmeur de s'assurer que son code est portable. Ce qui montre bien que la norme ne l'assure pas.
CQFD.
On ne peut pas dire que je pisse du C à longueur de journée, mais je connais quand même les bases.
Le problème, c'est que t'as visiblement jamais bosser sur un vrai projet en C : la vraie vie, c'est que t'as intérêt de faire gaffe quand tu codes en C si tu veux qu'il soit portable, et t'as sacrément besoin de vérifier. T'appelles ça des "erreurs" de programmation si tu veux, le fait est que le compilateur ne t'offre aucune garantie que le code que tu pondes soit portable, et pour cause, la norme l'oblige à faire un choix qui ne sera pas le même que celui du voisin.
D'ailleurs, quelque chose qui montre bien que la norme ANSI C n'est pas un garant de portabilité (même si son respect met le code sur la bonne voie), c'est le nombre de "guide" pour le programmeur afin qu'il fasse attention à la portabilité du code qu'il écrit :
"Guide pour la portabilité" : http://docs.hp.com/en/B3901-90005/ch05s02.html
http://serghei.net/docs/programming/autobook-1.1/writing20po(...) (citation rigolote : "The C language makes it easy to write non-portable code")
Le mythe de la portabilité du C : http://spinning-yarns.org/blog/?p=451
http://www.psgd.org/paul/docs/cstyle/cstyle16.htm (avec ma préférée : "C combines the power of assembler with the portability of assembler. " )
http://unixwiz.net/about/porting.html ( "Ultimately, most software porters created portability macros that allowed the use of many of these features in code that could be straight K&R or ANSI.")
Voilà la vraie vie de nombreuses personnes. Rien à voir visiblement avec ton expérience personnelle.
Quand tu codes en Java ou en C#, t'es pas en train de poser des questions sur le fait que ton code soit portable ou non en fonction de l'architecture matérielle, tu te demandes juste si les libs que tu utilises sont portables (cad s'appui sur du code natif portable ou non) : ce sont des beaucoup plus portables que le ANSI C.