Discussion :

[nicolas.sitbon]

Ok autant pour moi, merci pour ces explications (je pense quand même que dans des cas comme ça, il faut préciser, sur quelle version de la norme on s'appuie) Emmanuel, et mes excuses à Thierry Chappuis et bien évidemment à Jessee Edouard (melem).
Cordialement.

[c-candide]

C'est ce qu'on veut et cette définition ne me choc donc pas, car parfaitement valide.
Thierry

La norme dit :

Introduction

Certain features are obsolescent, which means that they may be considered for
withdrawal in future revisions of this International Standard. They are retained because
of their widespread use, but their use in new implementations (for implementation
features) or new programs (for language [6.11] or library features [7.26]) is discouraged.

et dans une annexe :

6.11.6 Function declarators
1 The use of function declarators with empty parentheses (not prototype-format parameter
type declarators) is an obsolescent feature



Au demeurant, cela n'empêche pas la norme de ne pas donner l'exemple puisqu'on trouve plusieurs exemples en int main().

Harbison & Steele disent :

(page 303)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int main(void){...} /* */
int main(){...} /* Also OK, but not recommended  */

C'est une mise en garde contre le risque de mauvais usage. En effet, il est techniquement possible de coder :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
void f ()
{
}
 
int main (void)
{
   f (123);
   return 0;
}

Ce qui ne provoque (...) ni comportement indéterminé,

Ah, bon ? alors que veut dire ceci



6.5.2.2 Function calls
(...)
6 If the expression that denotes the called function has a type that does not include a
prototype, (...). If the number of arguments does not equal the number of parameters, the
behavior is undefined.


qui est repris en annexe J2 (liste des comportements indéterminés) ?

[Emmanuel Delahaye]

qui est repris en annexe J2 (liste des comportements indéterminés) ?

OK, le comportement est indéterminé.

[Thierry Chappuis]

6.11.6 Function declarators
1 The use of function declarators with empty parentheses (not prototype-format parameter
type declarators) is an obsolescent feature

Soit, je prends note et je te remercie de cette précision.

Meilleures salutations

Thierry

[Melem]

Juste pour les explications car il y a déjà plein de textes de référence cités comme ça ...

En effet, il est techniquement possible de coder :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
void f ()
{
}
 
int main (void)
{
   f (123);
   return 0;
}

Ce qui ne provoque ni remarques supplémentaires de la part du compilateur, ni comportement indéterminé,

f est une fonction qui n'accepte aucun argument. f(123) est donc un erreur. Par contre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void f();
 
int main (void)
{
   f (123);
   return 0;
}
 
void f (int n)
{
    ...
}

Est parfaitement valide.

void entre les parenthèses, dans une définition, est totalement facultatif. Dans une déclaration void entre les parenthèses est obligatoire pour spécifier que la fonction n'accepte aucun argument.

6.11.6 Function declarators
1 The use of function declarators with empty parentheses (not prototype-format parameter type declarators) is an obsolescent feature

Oui, dans C2036. La norme certes dit qu'il est possible que dans les versions futures les parenthèses vides dans une définition ne seront peut-être plus valides, mais pour l'heure, elles sont parfaitement valides (et la preuve comme tu l'as donné les exemples dans le document continuent à utiliser la forme int main() ).

En tou cas la perfection n'existe pas (même la norme n'est pas parfaite : gets, etc.).

Par exemple dans le tuto de cet autre site tout naze :

TRES IMPORTANT : toute instruction se termine O-BLI-GA-TOI-RE-MENT par un point-virgule " ; ". C’est d’ailleurs comme ça qu’on reconnaît ce qui est une instruction et ce qui n’en est pas une. Si vous oubliez de mettre un point-virgule à la fin d’une instruction, votre programme ne compilera pas !

C'est faux. Certaines instructions se terminent par un point-virgule. Ceci ne sert à rien mais juste pour illustrer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

while (1) {}

Pas de point-virgule. Mais ca compile.

Selon le tutoriel, la taille des types est défini par le langage (indépendamment du processeur).

La définition de fonctions n'acceptant aucun paramètre se fait avec des parenthèses vides (se qui est conforme à la norme).

Bref. Les tutoriels C sont là pour aider les gens à apprendre le langage, pas pour définir le langage.

[Thierry Chappuis]

La définition de fonctions n'acceptant aucun paramètre se fait avec des parenthèses vides (se qui est conforme à la norme).

Pour éviter les discussions inutiles, et surtout par soucis de symétrie entre déclaration et définition, je trouve tout de même plus rationnel d'utiliser void pour spécifier qu'une fonction ne prend aucun argument. Mais la version avec parenthèses vide est parfaitement valide (bien que dans le cadre d'une tuto, je conseillerais plus de symétrie entre déclaration et définition. Le langage C est déjà assez subtile comme cela).

Thierry

[Melem]

Ce ne sont pas des discussions inutiles. Savoir que void est en fait facultatif dans une définition est même très important. Faire croire le contraire au lecteur c'est tout simplement lui mentir. Si on vous a appris qu'il faut mettre void entre les parenthèses dans la définition d'une fonction sans argument, comment vous sentirez-vous lorsque vous tomberez un jour sur un code qui les laisse vide ?

[c-candide]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
void f();
 
int main (void)
{
   f (123);
   return 0;
}
 
void f (int n)
{
    ...
}

Est parfaitement valide.

Je t'avoue que je n'en sais rien et je n'ai pas envie de passer 2 heures dans la norme pour trancher cette question (et essentiellement parce que son intérêt me paraît mineur). Pour faire simple, je vais te donner des extraits de Harbison & Steele qui à mon avis connaissent assez bien la norme (un des deux voire les deux étaient membres du Committee) :

There are three basic kinds of prototypes depending on whether (...)

1. A function that has no parameter must have a parameter type list consisting of the single type specifier void. In a function definition, an empty parameter list means the same as void but it is an obsolescent notation that should be avoided.
2. (...)
3. (...)

Donc je crois pouvoir interpréter que le code que tu proposes ci-dessus contient une déclaration de f qui n'est pas sous forme de prototype, c'est un mix des deux, là tu rentres dans le cadre du §9.2.2 de Harbison & Steele ("Mixing Prototype and Nonprotype Declarations") où il est dit que cet usage n'est pas recommandé. Et dans ce même paragraphe, il passe en revue les différentes situations de compatibilité entre forme prototype et non prototype, quel pensum !
Le C est assez compliqué pour qu'en 2008 on n'ait pas à se soucier à écrire du code compatible avec des compilateurs de 1978.

Oui, dans C2036.

Sans doute, mais c'est plutôt une question d'homogeneité du code : pas la peine en 2008 de multiplier les façon de coder la même chose.

[Thierry Chappuis]

Ce ne sont pas des discussions inutiles. Savoir que void est en fait facultatif dans une définition est même très important. Faire croire le contraire au lecteur c'est tout simplement lui mentir. Si on vous a appris qu'il faut mettre void entre les parenthèses dans la définition d'une fonction sans argument, comment vous sentirez-vous lorsque vous tomberez un jour sur un code qui les laisse vide ?

Je t'avoue que, dans le contexte d'une intro au C pour débutants, je trouve l'argument étrange.

Thierry

[c-candide]

Ce ne sont pas des discussions inutiles. Savoir que void est en fait facultatif dans une définition est même très important.

Franchement, il y a des choses beaucoup beaucoup plus importantes que ça quand on apprend le C.

Faire croire le contraire au lecteur c'est tout simplement lui mentir.

Comme tu y vas fort, ce n'est plus de la rigueur, c'est du rigorisme !

Si on vous a appris qu'il faut mettre void entre les parenthèses dans la définition d'une fonction sans argument, comment vous sentirez-vous lorsque vous tomberez un jour sur un code qui les laisse vide ?

D'abord, il faut bien distinguer le code qu'on produit soi-même et le code qu'on lit.
D'autre part, je ne vois pas en quoi quelqu'un qui découvrira ça pourra se sentir mal, il suffit d'expliquer que c'est le résultat d'un souhait de compatibilité ascendante. Et franchement, il rencontrera des choses autrement plus tordues que ça dans du code des autres. Enfin, si les programmeurs et les enseignants de C avaient suivi, depuis 1988, les recommandations de la norme ANSI concernant void pour l'absence de paramètre, on en serait pas encore à ce genre de discussions oiseuses. Le C est ailleurs.

Par ailleurs, il ne faut pas sous estimer le risque de confusion chez les débutants entre un f() qui est une déclaration de fonction et un f() qui est un appel de fonction.

Personnellement, je pense qu'un enseignement de C doit obliger à utiliser des déclarations sous forme de prototype et même doit complètement ignorer toutes les questions de compatibilité avec le C d'avant la normalisation. Ensuite, si quelqu'un doit remanier du C pré-ANSI, je suppose qu'elle aura le background pour se mettre à jour seule.

[nicolas.sitbon]

A la page 7, on a:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#include <stdio.h> // Directive de preprocesseur
void main() {
    printf("Hello world!");
}

Ca commence plutôt mal!

Thierry

Désolé de rebondir la dessus aussi tard, mais connaissant les auteurs, je ne peux m'empêcher de les défendre :
Sébastien Varette et Nicolas Bernard sont auteurs de l'ouvrage Programmation avancée en C qui est un excellent ouvrage,
traitant entre autre de C99, et il le fait bien, le poly que tu cites Thierry date, il n'y a qu'à lire leur livre pour s'en rendre compte.
A ce sujet, j'ai contacté les auteurs, leur réponse a été immédiate, il était là par oubli, ils l'ont supprimé dès que je le leur ai rappelé.
Je cite au passage les sites respectifs des deux auteurs pour ceux qui voudraient en savoir un peu plus sur eux.

Sébastien Varette : http://www-id.imag.fr/~svarrett/perso.html
Nicolas Bernard : http://www.lafraze.net/nbernard/
et leur ouvrage : http://c.lafraze.net/index.html

Cordialement.

[Thierry Chappuis]

Désolé de rebondir la dessus aussi tard, mais connaissant les auteurs, je ne peux m'empêcher de les défendre :
Sébastien Varette et Nicolas Bernard sont auteurs de l'ouvrage Programmation avancée en C qui est un excellent ouvrage,
traitant entre autre de C99, et il le fait bien, le poly que tu cites Thierry date, il n'y a qu'à lire leur livre pour s'en rendre compte.
A ce sujet, j'ai contacté les auteurs, leur réponse a été immédiate, il était là par oubli, ils l'ont supprimé dès que je le leur ai rappelé.
Je cite au passage les sites respectifs des deux auteurs pour ceux qui voudraient en savoir un peu plus sur eux.

Sébastien Varette : http://www-id.imag.fr/~svarrett/perso.html
Nicolas Bernard : http://www.lafraze.net/nbernard/
et leur ouvrage : http://c.lafraze.net/index.html

Cordialement.

Je n'ai porté absolument aucun jugement de valeur sur les auteurs. Je ne dute pas que Sébastien Varette et Nicolas Bernard des auteurs compétents. Je n'ai malheureusement pas eu l'occasion de voir passer leur ouvrages dans mes mains. Je vais voir à la bibliothèque pour me faire une idée.

Thierry

[nicolas.sitbon]

Je n'ai porté absolument aucun jugement de valeur sur les auteurs.

Je n'ai pas dis ça Thierry, c'était simplement pour dire que le document cité n'est pas à jour (on l'avait tous remarqué d'ailleurs)...
Si tu as l'occasion de lire leur ouvrage, vas-y
Cordialement.

[Emmanuel Delahaye]

Personnellement, je pense qu'un enseignement de C doit obliger à utiliser des déclarations sous forme de prototype et même doit complètement ignorer toutes les questions de compatibilité avec le C d'avant la normalisation. Ensuite, si quelqu'un doit remanier du C pré-ANSI, je suppose qu'elle aura le background pour se mettre à jour seule.

+1

[Melem]

Personnellement, je pense qu'un enseignement de C doit obliger à utiliser des déclarations sous forme de prototype et même doit complètement ignorer toutes les questions de compatibilité avec le C d'avant la normalisation. Ensuite, si quelqu'un doit remanier du C pré-ANSI, je suppose qu'elle aura le background pour se mettre à jour seule.

T'as vu une partie dans le document où je me souciais du C pré-ANSI ?

[snake264]

Au risque de me fair crier dessus personnellement (et c'est comme sa qu'on me l'apprend à la fac) chacun doit peut avoir son style de programmation tout en respectant biensur une norme (ansi, c99 ou autre). Après c'est au dir de chacun tout les programmeurs ont leur petites habitudes avec lesquels ils se sentent bien.

[Emmanuel Delahaye]

Au risque de me fair crier dessus personnellement (et c'est comme sa qu'on me l'apprend à la fac) chacun doit peut avoir son style de programmation tout en respectant biensur une norme (ansi, c99 ou autre). Après c'est au dir de chacun tout les programmeurs ont leur petites habitudes avec lesquels ils se sentent bien.

J'ai rien compris. Tu peux le refaire en français.

[snake264]

Roo je m'exprime si mal que sa je voulais juste dir que chaque programmeur à son style de programmation du moment qu'il respecte une norme quelle qu'elle soit, car de toute manière personne ne peut coder de la même façon. Enfin moi c'est comme cela qu'on me l'a enseigné à ma première année de fac.

[Thierry Chappuis]

Roo je m'exprime si mal que sa je voulais juste dir que chaque programmeur à son style de programmation du moment qu'il respecte une norme quelle qu'elle soit, car de toute manière personne ne peut coder de la même façon. Enfin moi c'est comme cela qu'on me l'a enseigné à ma première année de fac.

Il ne me semble pas que les points discutés dans ce fil relèvent tellement d'une question purement stylistiques.

Thierry

[madlove40]

il y a eu un petit malentendue je sais parfaitement quil existe aucun langage qui s'appele c/c++ , enfaite elle sont assez similaires c pour cela que jai simplement ecris c/c++ au lieu d'ecrire c et c++.je suis nul en programmation mais pas a ce point la.disons que c++ nest qune version amelioree de c.