%d ou %i ?

Christophe Le Gal

19/08/2003 à 23:06

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.

C'est vrai que le =+ c'etait pas joli.
Comme je suis de la generation qui ne l'a pas jamais utilise, sa
disparition ne me derange pas.
Mais je suppose que les gens qui ont de vieux programmes utilisant =+
ne doivent pas penser comme moi.

--
Christophe Le Gal

Vincent Lefevre

19/08/2003 à 23:19

Dans l'article ,
Christophe Le Gal écrit:

C'est quoi une magie a la tgmath.h ?

Ce n'est pas tgmath.h, mais <tgmath.h>.

--
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

Gabriel Dos Reis

19/08/2003 à 23:42

Christophe Le Gal writes:

| >| 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".

ah !?

[...]

| > 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 ?

Pour résumer, une magie à la <tgmath.h>, c'est une magie que la
bibliothèque peut faire, mais qui est interdite au programmeur,
i.e. une magie pas très impressionante.

| 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.

Alors, voilà. Le C a définit dans l'en-tête <math.h> des familles de
fonctions avec une convention de nommage d'inspiration hongroise

[#1] The header <math.h> declares two types and many
mathematical functions and defines several macros. Most
synopses specify a family of functions consisting of a
principal function with one or more double parameters, a
double return value, or both; and other functions with the
same name but with f and l suffixes, which are corresponding
functions with float and long double parameters, return
values, or both.189) Integer arithmetic functions and
conversion functions are discussed later.

Ainsi, par exemple fabs() travaille sur les doubles, fabsf() travaille
sur les float et fabsl() travaille sur les long double.
Seulement voilà, les numériciens aiment bien la généricité, i.e. ils
aimeraient bien écrire le nom d'une fonction et que le compilateur se
débrouille vace le reste puisque de toute façon il a le type de
l'argument sous les yeux. Mais le comité C ne veut pas entrendre
parler de surcharge de fonction, alors ils ont inventé la notion de
« type-generic macro ». Un machin que seule la bibliothèque peut
définir et pas le programmeur. Voici la sémantique

7.22 Type-generic math <tgmath.h>

[#1] The header <tgmath.h> includes the headers <math.h> and
<complex.h> and defines several type-generic macros.

[#2] Of the <math.h> and <complex.h> functions without an f
(float) or l (long double) suffix, several have one or more
parameters whose corresponding real type is double. For
each such function, except modf, there is a corresponding
type-generic macro.263) The parameters whose corresponding
real type is double in the function synopsis are generic
parameters. Use of the macro invokes a function whose
corresponding real type and type domain are determined by
the arguments for the generic parameters.264)

[#3] Use of the macro invokes a function whose generic
parameters have the corresponding real type determined as
follows:

-- First, if any argument for generic parameters has type
long double, the type determined is long double.

-- Otherwise, if any argument for generic parameters has
type double or is of integer type, the type determined
is double.

-- Otherwise, the type determined is float.

[#4] For each unsuffixed function in <math.h> for which
there is a function in <complex.h> with the same name except
for a c prefix, the corresponding type-generic macro (for
both functions) has the same name as the function in
<math.h>. The corresponding type-generic macro for fabs and
cabs is fabs.

Peux-tu écrire l'une de ces macro génériques avec les seules
fonctionnalités de CPP comme défini dans le langage ?
(Ne me réponds pas que c'est pour cela que c'est dans la
bibliothèque).

| N'est-il pas possible d'etendre un langage autrement que via
| des bibliotheques ?

oh, il est possible d'étendre un langage de plusieurs manières.

Mais je suis de l'opinion qu'un langage doit fournir des primitives
*générales* assez expressives pour pouvoir écrire des bibliothèques
efficaces et complexes. Je crois très peu en les magies.

| 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.

Je le sais. Je passe une partie de mon temps à faire cela.

| 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 je considère de tels programmes C pathologiques et sérieusement
endommagés -- oui, je sais qu'il y en a beaucoup ; et je travaille
même au quotidien sur quelques uns d'entre eux.

| Mais c'est quand meme faisable non ?

Tout est possible. Dans les limites du prix que l'on veut payer.

-- Gaby

Christophe Le Gal <christophe-n2@vinigou.org> writes:

| >| 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".

ah !?

[...]

| > 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 ?

Pour résumer, une magie à la <tgmath.h>, c'est une magie que la
bibliothèque peut faire, mais qui est interdite au programmeur,
i.e. une magie pas très impressionante.

| 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.

Alors, voilà. Le C a définit dans l'en-tête <math.h> des familles de
fonctions avec une convention de nommage d'inspiration hongroise

[#1] The header <math.h> declares two types and many
mathematical functions and defines several macros. Most
synopses specify a family of functions consisting of a
principal function with one or more double parameters, a
double return value, or both; and other functions with the
same name but with f and l suffixes, which are corresponding
functions with float and long double parameters, return
values, or both.189) Integer arithmetic functions and
conversion functions are discussed later.

Ainsi, par exemple fabs() travaille sur les doubles, fabsf() travaille
sur les float et fabsl() travaille sur les long double.
Seulement voilà, les numériciens aiment bien la généricité, i.e. ils
aimeraient bien écrire le nom d'une fonction et que le compilateur se
débrouille vace le reste puisque de toute façon il a le type de
l'argument sous les yeux. Mais le comité C ne veut pas entrendre
parler de surcharge de fonction, alors ils ont inventé la notion de
« type-generic macro ». Un machin que seule la bibliothèque peut
définir et pas le programmeur. Voici la sémantique

7.22 Type-generic math <tgmath.h>

[#1] The header <tgmath.h> includes the headers <math.h> and
<complex.h> and defines several type-generic macros.

[#2] Of the <math.h> and <complex.h> functions without an f
(float) or l (long double) suffix, several have one or more
parameters whose corresponding real type is double. For
each such function, except modf, there is a corresponding
type-generic macro.263) The parameters whose corresponding
real type is double in the function synopsis are generic
parameters. Use of the macro invokes a function whose
corresponding real type and type domain are determined by
the arguments for the generic parameters.264)

[#3] Use of the macro invokes a function whose generic
parameters have the corresponding real type determined as
follows:

-- First, if any argument for generic parameters has type
long double, the type determined is long double.

-- Otherwise, if any argument for generic parameters has
type double or is of integer type, the type determined
is double.

-- Otherwise, the type determined is float.

[#4] For each unsuffixed function in <math.h> for which
there is a function in <complex.h> with the same name except
for a c prefix, the corresponding type-generic macro (for
both functions) has the same name as the function in
<math.h>. The corresponding type-generic macro for fabs and
cabs is fabs.

Peux-tu écrire l'une de ces macro génériques avec les seules
fonctionnalités de CPP comme défini dans le langage ?
(Ne me réponds pas que c'est pour cela que c'est dans la
bibliothèque).

| N'est-il pas possible d'etendre un langage autrement que via
| des bibliotheques ?

oh, il est possible d'étendre un langage de plusieurs manières.

Mais je suis de l'opinion qu'un langage doit fournir des primitives
*générales* assez expressives pour pouvoir écrire des bibliothèques
efficaces et complexes. Je crois très peu en les magies.

| 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.

Je le sais. Je passe une partie de mon temps à faire cela.

| 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 je considère de tels programmes C pathologiques et sérieusement
endommagés -- oui, je sais qu'il y en a beaucoup ; et je travaille
même au quotidien sur quelques uns d'entre eux.

| Mais c'est quand meme faisable non ?

Tout est possible. Dans les limites du prix que l'on veut payer.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

Christophe Le Gal writes:

| >| 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".

ah !?

[...]

| > 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 ?

Pour résumer, une magie à la <tgmath.h>, c'est une magie que la
bibliothèque peut faire, mais qui est interdite au programmeur,
i.e. une magie pas très impressionante.

| 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.

Alors, voilà. Le C a définit dans l'en-tête <math.h> des familles de
fonctions avec une convention de nommage d'inspiration hongroise

[#1] The header <math.h> declares two types and many
mathematical functions and defines several macros. Most
synopses specify a family of functions consisting of a
principal function with one or more double parameters, a
double return value, or both; and other functions with the
same name but with f and l suffixes, which are corresponding
functions with float and long double parameters, return
values, or both.189) Integer arithmetic functions and
conversion functions are discussed later.

Ainsi, par exemple fabs() travaille sur les doubles, fabsf() travaille
sur les float et fabsl() travaille sur les long double.
Seulement voilà, les numériciens aiment bien la généricité, i.e. ils
aimeraient bien écrire le nom d'une fonction et que le compilateur se
débrouille vace le reste puisque de toute façon il a le type de
l'argument sous les yeux. Mais le comité C ne veut pas entrendre
parler de surcharge de fonction, alors ils ont inventé la notion de
« type-generic macro ». Un machin que seule la bibliothèque peut
définir et pas le programmeur. Voici la sémantique

7.22 Type-generic math <tgmath.h>

[#1] The header <tgmath.h> includes the headers <math.h> and
<complex.h> and defines several type-generic macros.

[#2] Of the <math.h> and <complex.h> functions without an f
(float) or l (long double) suffix, several have one or more
parameters whose corresponding real type is double. For
each such function, except modf, there is a corresponding
type-generic macro.263) The parameters whose corresponding
real type is double in the function synopsis are generic
parameters. Use of the macro invokes a function whose
corresponding real type and type domain are determined by
the arguments for the generic parameters.264)

[#3] Use of the macro invokes a function whose generic
parameters have the corresponding real type determined as
follows:

-- First, if any argument for generic parameters has type
long double, the type determined is long double.

-- Otherwise, if any argument for generic parameters has
type double or is of integer type, the type determined
is double.

-- Otherwise, the type determined is float.

[#4] For each unsuffixed function in <math.h> for which
there is a function in <complex.h> with the same name except
for a c prefix, the corresponding type-generic macro (for
both functions) has the same name as the function in
<math.h>. The corresponding type-generic macro for fabs and
cabs is fabs.

Peux-tu écrire l'une de ces macro génériques avec les seules
fonctionnalités de CPP comme défini dans le langage ?
(Ne me réponds pas que c'est pour cela que c'est dans la
bibliothèque).

| N'est-il pas possible d'etendre un langage autrement que via
| des bibliotheques ?

oh, il est possible d'étendre un langage de plusieurs manières.

Mais je suis de l'opinion qu'un langage doit fournir des primitives
*générales* assez expressives pour pouvoir écrire des bibliothèques
efficaces et complexes. Je crois très peu en les magies.

| 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.

Je le sais. Je passe une partie de mon temps à faire cela.

| 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 je considère de tels programmes C pathologiques et sérieusement
endommagés -- oui, je sais qu'il y en a beaucoup ; et je travaille
même au quotidien sur quelques uns d'entre eux.

| Mais c'est quand meme faisable non ?

Tout est possible. Dans les limites du prix que l'on veut payer.

-- Gaby

Christophe Le Gal

20/08/2003 à 00:21

| C'est quoi une magie a la tgmath.h ?

Pour résumer, une magie à la <tgmath.h>, c'est une magie que la
bibliothèque peut faire, mais qui est interdite au programmeur,
i.e. une magie pas très impressionante.

[...]

Merci pour l'info.

l'argument sous les yeux. Mais le comité C ne veut pas entrendre
parler de surcharge de fonction, alors ils ont inventé la notion de
« type-generic macro ». Un machin que seule la bibliothèque peut
définir et pas le programmeur. Voici la sémantique
[...]
Peux-tu écrire l'une de ces macro génériques avec les seules
fonctionnalités de CPP comme défini dans le langage ?

Certes non.
Le point que je ne comprends pas ici, est pourquoi le comite C
refuse la surcharge et accepte la magie ?
La surcharge, tant qu'on ne parle pas de conversion implicite,
n'est-elle pas une "extension" dans le sens ou je l'entendais ?
Tous les programmes legals sans la surcharge restent inchanges
avec, et seuls des programmes autrefois illegaux le deviennent. non ?

mais je considère de tels programmes C pathologiques et sérieusement
endommagés -- oui, je sais qu'il y en a beaucoup ; et je travaille
même au quotidien sur quelques uns d'entre eux.

Yep. La lib X11 par exemple.

Tout est possible. Dans les limites du prix que l'on veut payer.

Je suppose que le prix que l'on veut payer pour faire une telle
extension (qui garde la compatibilite) est directement en
relation avec les emmerdes que l'on aura si on abandonne la
compatibilite, et avec l'apport de l'extension.

Ce qui nous ramene au point sur lequel nous sommes deja tombe d'accord :
enlever le %i n'apportera pas des masses de choses posivitives, mais
beaucoup d'emmerdes.

--
Christophe Le Gal

Gabriel Dos Reis

20/08/2003 à 00:28

Christophe Le Gal writes:

[...]

| > Peux-tu écrire l'une de ces macro génériques avec les seules
| > fonctionnalités de CPP comme défini dans le langage ?
|
| Certes non.
| Le point que je ne comprends pas ici, est pourquoi le comite C
| refuse la surcharge et accepte la magie ?

probablement parce que la surcharge est C++ et pas les macros en
question ? Je ne sais pas.

| La surcharge, tant qu'on ne parle pas de conversion implicite,
| n'est-elle pas une "extension" dans le sens ou je l'entendais ?

oui, mais il faut aussi prendre en compte des aspects « politiques ».

| Tous les programmes legals sans la surcharge restent inchanges
| avec, et seuls des programmes autrefois illegaux le deviennent. non ?

Normalement, oui. Sauf s'ils font des hypothèse infondées.

| > mais je considère de tels programmes C pathologiques et sérieusement
| > endommagés -- oui, je sais qu'il y en a beaucoup ; et je travaille
| > même au quotidien sur quelques uns d'entre eux.
|
| Yep. La lib X11 par exemple.

Yep. Ou le très familier GCC ;-)

| > Tout est possible. Dans les limites du prix que l'on veut payer.
|
| Je suppose que le prix que l'on veut payer pour faire une telle
| extension (qui garde la compatibilite) est directement en
| relation avec les emmerdes que l'on aura si on abandonne la
| compatibilite, et avec l'apport de l'extension.

comment est-ce que tous ces élements interviennent dans le calcul du
prix final n'est pas très clair mais il est certain que le comité ne
casserait du code existant que pour une très Bonne Raison.

-- Gaby

Christophe Le Gal

21/08/2003 à 11:38

| Le point que je ne comprends pas ici, est pourquoi le comite C
| refuse la surcharge et accepte la magie ?

probablement parce que la surcharge est C++ et pas les macros en
question ? Je ne sais pas.
[...]
oui, mais il faut aussi prendre en compte des aspects « politiques ».

En d'autres termes "faudrait pas avoir l'air de suivre C++". C'est ca ?

--
Christophe Le Gal

Laurent Deniau

21/08/2003 à 18:05

Vincent Lefevre wrote:

Dans l'article ,
Gabriel Dos Reis écrit:

%i comme int, "%p" comme pointer, "%s" comme string sont plus
faciles à retenir que "%g" comme flottant ;-/

Mais %d comme décimal est plus facile à retenir que %i.

Sauf que decimal en anglais est un faux amis en francais. Tous les nombres
decimaux ne sont pas des entiers et entre deux decimaux il y a une infinite de
decimaux... C'est meme pire, un double represente un nombre decimal, dans la
limite de sa precision et en excluant les rationnels resultant du changement de
base, cela va de soi. Alors pour la confusion %d vs %i on est servi...

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Vincent Lefevre

21/08/2003 à 21:08

Dans l'article ,
Laurent Deniau écrit:

1913? D'apres le dico Oxford c'est plus vieux:

"For a historical sketch of the notation of decimal fractions, the
introduction of the decimal point, etc., see W. W. R. Ball, Short
Hist. Mathem. (1888)"

1913, c'est la date du dictionnaire, je suppose.

Ici, decimal, c'était pour la représentation: on écrit l'entier en
base 10.

les double aussi...

Oui, mais historiquement, contrairement aux entiers, on ne pouvait pas
sortir des double en hexa; c'était forcément en décimal.

--
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

Emmanuel Delahaye

28/08/2003 à 20:14

In 'fr.comp.lang.c', Jseb wrote:

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);

Strictement équivallent (pour printf()).

On m'a dit également que "%i" était une windozerie.

Faux.

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".

La différence est importante pour scanf(). Pour éviter les symétries
douteuses, je propose d'utiliser "%d" pour les entiers.

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye

28/08/2003 à 20:17

In 'fr.comp.lang.c', Gabriel Dos Reis wrote:

| Le format i est une vieillerie qui vient du Fortran. Hélas on ne peut

c'est dans les vieilles casseroles qu'on fait les meilleures soupes.

%i comme int, "%p" comme pointer, "%s" comme string sont plus faciles
à retenir que "%g" comme flottant ;-/

Certes, mais "%d" est "décimal", ce qui a son importance. (par rapport à "%o"
: octal ou %x : héxadécimal).

"%i" est flou! En fait, c'est décimal. (Comme "%d")

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

%d ou %i ?

10 réponses

Veuillez sélectionner un problème