Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage C %d ou %i ?

%d ou %i ?

55 réponses
Avatar
Jseb
Bonjour,

J'ai l'habitude d'écrire l'affichage des mes entiers avec printf sous
cette forme: printf("%i ",toto);

On m'a dit plusieurs fois qu'il fallait écrire: printf("%d ",toto);
On m'a dit également que "%i" était une windozerie. J'ai vérifié dans
le K&R, c'est équivalent (tableau p.152 2eme édition Masson)

Si quelqu'un a une explication cohérente (autre que "windozerie"), je
suis prêt à abandonner le "%i".

--
Alussinan, l'internette que ça fout la trouille.
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Jean Claude Calvez
"Éric Lévénez" a écrit dans le message news:
BB671D80.5131B%

Le format g vient aussi du Fortran donc facile à retenir.


A condition d'avoir fait du fortran avant d'avoir
fait du C !
(je ne pense pas que ce soit le cas de tout le
monde).

--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.


--

Jean Claude Calvez


Avatar
Gabriel Dos Reis
Christophe Le Gal writes:

|
| > surtout si %i comme int et %d pas comme double :-/
|
| Loin de moi l'idee d'essayer de trouver des moyens mnemotechniques pour
| le reste, mais en l'occurence ici %d pour decimal et %i pour integer

pour lever tout doute, je sais que "d" est pour decimal, tout comme
"o" est pour octal. Le point de la remarque est l'inconsistance du
nommage. (et si tu veux savoir, j'ai vécu en tant qu'enseignant le
fait que des débutants prenent "d" pour double surtout s'ils ont "f"
pour flottant)

-- Gaby
Avatar
Vincent Lefevre
Dans l'article ,
Gabriel Dos Reis écrit:

Vincent Lefevre <vincent+ writes:

| Dans l'article ,
| Gabriel Dos Reis écrit:
|
| > surtout si %i comme int et %d pas comme double :-/
| > et bien sûr, la première lettre %a pour dire hexa.
|
| Ben le 'h', le 'e' et le 'x' étant déjà pris, le 'a' n'est pas un
| si mauvais choix.

avec une définition adéquate de « mauvais ».

Je ne dis pas que « a » est un bon ou mauvois choix. Juste curieux.


Je pense que parfois, on n'a que des choix curieux. À moins que tu aies
une autre suggestion?

| Et que penser du '=' qui indique une affectation et non pas une égalité?
| et du '<<' qui indique un décalage est non pas 'est petit devant'?

ce sont des spécificateurs de format ?


Non, mais le problème est le même: un symbole (que ce soit une lettre
dans un spécificateur de format ou autre) n'indique pas forcément ce
que l'on pourrait penser.

| > | vient après %e (engineer notation) et %f (fixed point), est facile
| > | à retenir.
|
| > et %h qui vient après %g qui vient après %e pour dire short.
|
| 'h', c'est la 2e lettre de 'short', le 's' étant déjà pris pour 'string'.

'r' est la quatrième lettre de 'short'. C'est aussi celui de « court ».

Mais, là encore, je ne dis pas qu'il aurait fallu le prendre.

| Ce n'est pas un plus mauvais choix que le %s (qui peut vouloir dire
| string ou short).

cela n'en est pas un meilleur choix, mais juste un choix encore plus
curieux.


Si on veut. Il est surtout plus curieux du fait du nombre restreint de
possibilités (à moins de changer le système actuel des spécificateurs
de format).

| > %j pour dire intmat_t. C'est imparable comme moyen mnémotechnique.
|
| On pouvait difficilement reprendre 'i'.

pourquoi reprendre ?

| En revanche, 'm' m'aurait semblé un meilleur choix.

alors tu ne connais pas ce que POSIX en fait :-/


La libc5 de Linux l'utilise pour écrire strerror(errno), d'après
printf(3). Ensuite je n'ai aucune idée concernant les dates pour
lesquelles les divers choix ont été faits.

À ce propos, il me semble dommage que la norme C n'ait pas interdit
certains spécificateurs en tant qu'extension. Elle aurait dû spécifier
par exemple que %! soit utilisé pour les extensions, tout le reste
étant réservé pour les futures révisions de la norme.

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Avatar
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:

[...]

| Je pense que parfois, on n'a que des choix curieux. À moins que tu aies
| une autre suggestion?

Yep: adopter une charpente extensible et type-safe. Des extensions du
langage C en ont depuis au moins 1983 :-)

| > | Et que penser du '=' qui indique une affectation et non pas une égalité?
| > | et du '<<' qui indique un décalage est non pas 'est petit devant'?
|
| > ce sont des spécificateurs de format ?
|
| Non, mais le problème est le même: un symbole (que ce soit une lettre
| dans un spécificateur de format ou autre) n'indique pas forcément ce
| que l'on pourrait penser.

certes, mais dans le cadre de printf(), je trouve que le truc est devenu
abscon au possible.

[...]

| > | En revanche, 'm' m'aurait semblé un meilleur choix.
|
| > alors tu ne connais pas ce que POSIX en fait :-/
|
| La libc5 de Linux l'utilise pour écrire strerror(errno), d'après
| printf(3).

J'ai parlé plus vite que mon ombre, ce n'est pas encore dans la
spécification de POSIX.

| Ensuite je n'ai aucune idée concernant les dates pour
| lesquelles les divers choix ont été faits.

Je ne sais pas pourquoi et comment les choix ont été fait ; je ne
connais que le résultat.

http://www.opengroup.org/onlinepubs/007904975/functions/printf.html

| À ce propos, il me semble dommage que la norme C n'ait pas interdit
| certains spécificateurs en tant qu'extension.

cela n'aurait pas vraiment résolu le problème fondamental.
Ce qui est dommage, c'est le C ne prévoit pas une manière fiable
d'étendre les mécahismes d'entrée/sortie.

| Elle aurait dû spécifier par exemple que %! soit utilisé pour les
| extensions, tout le reste étant réservé pour les futures révisions
| de la norme.

je ne pense pas que cela résolve le problème.

-- Gaby
Avatar
Vincent Lefevre
Dans l'article ,
Gabriel Dos Reis écrit:

Yep: adopter une charpente extensible et type-safe. Des extensions du
langage C en ont depuis au moins 1983 :-)
[...]

certes, mais dans le cadre de printf(), je trouve que le truc est devenu
abscon au possible.
[...]

Ce qui est dommage, c'est le C ne prévoit pas une manière fiable
d'étendre les mécahismes d'entrée/sortie.


Je suis d'accord que le mécanisme actuel n'est pas terrible.
Notamment, c'est dommage qu'il n'y ait pas de pseudo-compatibilité
avec les anciennes implémentations (e.g. pour %zu). Et c'est bien
compliqué quand on utilise des typedef...

--
Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Avatar
Christophe Le Gal
pour lever tout doute, je sais que "d" est pour decimal, tout comme


Je n'en avais aucun

"o" est pour octal. Le point de la remarque est l'inconsistance du
nommage. (et si tu veux savoir, j'ai vécu en tant qu'enseignant le
fait que des débutants prenent "d" pour double surtout s'ils ont "f"
pour flottant)


Moi aussi j'ai vecu ca.
Ca n'enleve rien au fait qu'a la limite je ne trouve pas %i plus logique
que %d, ni l'inverse.
printf a besoin de savoir comment "lire" les donnees (comment interpreter
les octets qu'il va lire) et comment les "ecrire".
Certains types de donnees ont une forme canonique d'ecriture, ce qui rend
logique qu'une seule lettre designe les 2 a la fois
(eg %s : ya pas 36 facons d'ecire une chaine).
D'autres non.
Un entier ne s'ecrit pas forcement en decimal.

A la limite (mais franchement je m'en fous completement, et je ne me
pose la question qu'en tapant ce message), %d est plus logique que
%i, puisque tout ce qui s'ecrit en decimal est un entier (enfin la aussi
on peut discuter) alors que tout ce qui est entier ne s'ecrit pas
forcement en decimal.

D'ailleurs, je suppose que tu as aussi vecu les "monsieur, comment
on declare une variable hexadecimale ?", ou "comment on converti
un nombre en hexa ?".
Qq part c'est pas plus mal de rappeler que les notions de decimal ou
d'hexa sont une question d'affichage.

L'ideal aurait ete de dire des choses comme
%di, %oi, %ff, %ss (pour decimal-integer, octal-integer, fixed-float,
string-string).
Mais bon, ce n'est pas comme ca, et je trouve assez inutile de dire
"%d est bon, %i est obsolete, malheureusement on ne peut pas l'enlever
parce que ya des gens qui continuent a l'utiliser".
Un langage ca n'est pas fait pour changer de toutes facons.
Meme si plus personne n'utilisait le %i, si on decouvrait une bande DAT
dans une tombe egyptienne, je voudrais pouvoir compiler le code C
qui s'y trouve.

--
Christophe Le Gal

Avatar
Gabriel Dos Reis
Christophe Le Gal writes:

| > "o" est pour octal. Le point de la remarque est l'inconsistance du
| > nommage. (et si tu veux savoir, j'ai vécu en tant qu'enseignant le
| > fait que des débutants prenent "d" pour double surtout s'ils ont "f"
| > pour flottant)
|
| Moi aussi j'ai vecu ca.
| Ca n'enleve rien au fait qu'a la limite je ne trouve pas %i plus logique
| que %d, ni l'inverse.

quitte à choisir des lettres, autant les prendre au hasard. C'est plus
facile à expliquer.

| printf a besoin de savoir comment "lire" les donnees (comment interpreter
| les octets qu'il va lire) et comment les "ecrire".
| Certains types de donnees ont une forme canonique d'ecriture, ce qui rend

ah bon ?

| logique qu'une seule lettre designe les 2 a la fois
| (eg %s : ya pas 36 facons d'ecire une chaine).

Si.

| D'autres non.
| Un entier ne s'ecrit pas forcement en decimal.

sans blague.

| A la limite (mais franchement je m'en fous completement, et je ne me
| pose la question qu'en tapant ce message), %d est plus logique que

je ne trouve pas.

| %i, puisque tout ce qui s'ecrit en decimal est un entier (enfin la aussi
| on peut discuter)

si on peut discuter alors c'est que ce n'est pas plus logique.

[...]

| L'ideal aurait ete de dire des choses comme
| %di, %oi, %ff, %ss (pour decimal-integer, octal-integer, fixed-float,
| string-string).

ce n'est idéal pour moi.

| Mais bon, ce n'est pas comme ca, et je trouve assez inutile de dire
| "%d est bon, %i est obsolete, malheureusement on ne peut pas l'enlever
| parce que ya des gens qui continuent a l'utiliser".

%i n'est pas plus obsolète que %d.

| Un langage ca n'est pas fait pour changer de toutes facons.

si le lanage ne peut pas changer et s'adapter aux besoins, il faut
l'enterrer ;-/

-- Gaby
Avatar
Gabriel Dos Reis
Christophe Le Gal writes:

[...]

| >| Un langage ca n'est pas fait pour changer de toutes facons.
| >
| > si le lanage ne peut pas changer et s'adapter aux besoins, il faut
| > l'enterrer ;-/
|
| On peut l'etendre. Mais fixer des conventions pour les changer ensuite
| ca ne me semble pas une bonne idee.

Je n'ai vu personne proposer cela dans cette discussion.

| Je ne suis pas integriste non plus :
| Je concois que ca puisse etre un moindre mal. Mais supprimer le "%i"
| n'apporterait pas grand chose, a part des emmerdements.

C'est clair. Pareil pour le déclarer obsolète.

| Et si vraiment on estime que des morceaux existants du langage sont
| incompatibles avec les besoins actuels et qu'il faudrait
| les supprimer, alors effectivement il vaut mieux enterrer le
| langage que de le rendre incompatible avec les programmes qui etaient
| la d'abord.

On n'a pas besoin de supprimer, on peut mettre en place d'autres
mécanismes. Mais le C est déclaré pratiquement figé : en ce qui
concerne le core language, le comité est en mode maintenance ; il peut
par contre ajouter des choses à la bibliothèque.
Mais je doute que pour améliorer les facilités d'entrée sorties, une
extension bibliothèque soit suffisante -- à moins bine sûr d'inventer
des magies à la <tgmath.h>

-- Gaby
Avatar
Christophe Le Gal
| On peut l'etendre. Mais fixer des conventions pour les changer ensuite
| ca ne me semble pas une bonne idee.

Je n'ai vu personne proposer cela dans cette discussion.


Moi j'ai vu qqn regretter le fait qu'on ne puisse pas supprimer
le "%i" parce que "trop" de programmeurs l'utilisent "encore".

| Je ne suis pas integriste non plus :
| Je concois que ca puisse etre un moindre mal. Mais supprimer le "%i"
| n'apporterait pas grand chose, a part des emmerdements.

C'est clair. Pareil pour le déclarer obsolète.


Oui. Je crois qu'il y a eu une mecomprehension d'un de mes posts
(decidemment je n'arrive vraiment pas a me faire comprendre) : je
ne suis d'accord ni avec la suppression de %i, ni avec le fait
de le considerer obsolete, ni meme avec le fait de le considerer
"moins bien".
On parle seulement ici de savoir lequel est le plus facile a retenir.

Mais je doute que pour améliorer les facilités d'entrée sorties, une
extension bibliothèque soit suffisante -- à moins bine sûr d'inventer
des magies à la <tgmath.h>


C'est quoi une magie a la tgmath.h ?
J'ai bien un header comme ca, et en effet a vue de nez il a l'air
de contenir pas mal de #define "magique", mais j'ai la flemme
de chercher a comprendre le but.

N'est-il pas possible d'etendre un langage autrement que via
des bibliotheques ?
Du moment que tout programme correct avec le langage non etendu
reste correct, et signifie la meme chose avec le langage etendu ?
Ca n'est pas facile. Par exemple C++ n'est pas dans ce sens une
"extension" de C, puisque un programme en C contenant une variable
nommee "class" ne fonctionnera pas en C++.
Mais c'est quand meme faisable non ?

--
Christophe Le Gal

Avatar
Éric Lévénez
Le 19/08/03 21:33, dans ,
« Christophe Le Gal » a écrit :

| On peut l'etendre. Mais fixer des conventions pour les changer ensuite
| ca ne me semble pas une bonne idee.

Je n'ai vu personne proposer cela dans cette discussion.


Moi j'ai vu qqn regretter le fait qu'on ne puisse pas supprimer
le "%i" parce que "trop" de programmeurs l'utilisent "encore".


Oui, moi. Je n'aime pas le %i, c'est un fait. Mais je n'ai pas dit de le
supprimer, mais uniquement que c'était hélas pas possible. Tout comme il
n'est pas possible de supprimer gets. Mais il y a du progrès avec =+ qui
n'est plus dans supporté par les compilos. Les vieux trucs peuvent ainsi
disparaître sans trop de casse.

--
Éric Lévénez -- <http://www.levenez.com>
Unix is not only an OS, it's a way of life.


1 2 3 4 5