comment debuter avec C/C++?

bjr!
j'aimerais svp savoir quelle est la meilleur façon d'apprendre C pas a pas? jai lancer des recherches sur google mais souvent on tombe sur de sites qui ne sont pas destiné au vraie debutants (ce qui ne savent absolument rien de C) mais qui sont destines a ceux qui ont des notions de C ou ce qui veulent juste un petits coup de pouce.merci de m'aides svp
P.S je ne connait absolument rien a C

Citation:

---

Envoyé par madlove40

bjr!
j'aimerais svp savoir quelle est la meilleur façon d'apprendre C pas a pas? jai lancer des recherches sur google mais souvent on tombe sur de sites qui ne sont pas destiné au vraie debutants (ce qui ne savent absolument rien de C) mais qui sont destines a ceux qui ont des notions de C ou ce qui veulent juste un petits coup de pouce.merci de m'aides svp
P.S je ne connait absolument rien a C

---

La première chose à comprendre est qu'il n'existe pas de C/C++. Il y a C et il y C++. Ce sont 2 langages différents.

Il y a des références de tutoriels sur ce site et sur le mien.

Si ton but est d'apprendre à programmer en C, tu peux essayer de commencer par: Bien débuter en langage C et Initiation au langage C

Pour C/C++, comme Emmanuel te l'a dit, ce langage n'existe pas.

Thierry

Voilà un tuto que j'utilise et qui m'aide beaucoup en C:
http://www-id.imag.fr/~svarrett/down...ly_cours_C.pdf

Citation:

---

Envoyé par vg-matrix

Voilà un tuto que j'utilise et qui m'aide beaucoup en C:
http://www-id.imag.fr/~svarrett/down...ly_cours_C.pdf

---

A la page 7, on a:

Code:

---

1 2 3 4

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

---

Ca commence plutôt mal!

Thierry

Pour le C++ : http://mindview.net/Books/TICPP/ThinkingInCPP2e.html

Citation:

---

Envoyé par madlove40

bjr!
j'aimerais svp savoir quelle est la meilleur façon d'apprendre C pas a pas? Merci de m'aider svp

---

Donc tu veux apprendre le C. Le C++ c'est une autre histoire. Il y a de C et de C++ mais pas de C/C++.

Citation:

---

J'ai lancé des recherches sur google mais souvent on tombe sur de sites qui ne sont pas destinés au vrais débutants (ce qui ne savent absolument rien de C) mais qui sont destines a ceux qui ont des notions de C ou ce qui veulent juste un petits coup de pouce

---

La première chose dont tu auras besoin c'est bien sûr un tutoriel de C (j'en ai fais un). La deuxième qui n'est pas négligeable c'est un bon EDI (Environnement de Développement Intégré). En gros c'est un logiciel qui te permet de travailler (développer) avec ton langage favori. Pour le langage C, je recommande Code::Blocks qui est gratuit t très simple d'usage.

Citation:

---

Envoyé par Thierry Chappuis

A la page 7, on a:

Code:

---

1 2 3 4

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

---

Ca commence plutôt mal!

Thierry

---

Dans http://melem.developpez.com/langagec/initc/ que tu proposes :

Citation:

---

De plus on peut :

* Ne pas déclarer une fonction retournant un int (déconseillé).

Dans une définition (implémentation) :

* On peut ne pas préciser le type de retour d'une fonction. Dans ce cas celle-ci est supposée retourner un int.

* Une paire de parenthèses vide signifie que la fonction n'accepte aucun argument.

Autres remarques :

* La déclaration d'une fonction n'est nécessaire que lorsque son utilisation précède sa définition. Cependant, il est toujours conseillé de ne définir une fonction qu'après son utilisation (ce qui requiert donc une déclaration) ne serait-ce que pour la lisibilité du programme (en effet c'est le programme qu'on veut voir à première vue, pas les petits détails).

* Une fonction peut ne pas retourner de valeur. Son type de retour est alors void.

---

A REVOIR!!!

et je ne parle pas du

Code:

---

int main ()

---

que l'on retrouve un peu partout...

Citation:

---

Envoyé par nicolas.sitbon

et je ne parle pas du

Code:

---

int main ()

---

que l'on retrouve un peu partout...

---

Et alors ?

int main() ou plutôt int main(void) est totalement juste.

Extrait de la norme ISO C (ISO/IEC 9899:TC2)

Citation:

---

5.1.2.2.1 Program startup

1 The function called at program startup is named main. The implementation declares no
prototype for this function. It shall be defined with a return type of int and with no
parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though any names may be
used, as they are local to the function in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent or in some other implementation-defined manner.

---

Citation:

---

Envoyé par vicenzo

Et alors ?

int main() ou plutôt int main(void) est totalement juste.

)

---

et justement non, il y a une différence :

Code:

---

int main ()

---

est une déclaration de fonction alors que

Code:

---

int main (void)

---

est une déclaration plus un prototype.

A ce sujet, un compilateur correctement réglé (voir le site d'Emmanuel Delahaye) ne vous le pardonnera pas

Citation:

---

error : fonction declaration isn't a prototype

---

Tu fais bien de citer la norme puisque depuis C99 le prototype d'une fonction est obligatoire.
Enfin, la partie de la norme qui dit :

Citation:

---

or equivalent or in some other implementation-defined manner.

---

est expliqué juste en dessous :

Citation:

---

Thus, int can be replaced by a typedef name defined as int, or the type of argv can be written as
char ** argv, and so on.

---

Citation:

---

(informative)
Common warnings
1 An implementation may generate warnings in many situations, none of which are
specified as part of this International Standard. The following are a few of the more
common situations.

....

— A function is called but no prototype has been supplied (6.5.2.2).

---

Citation:

---

Envoyé par nicolas.sitbon

et justement non, il y a une différence :

Code:

---

int main ()

---

est une déclaration de fonction alors que

---

Ben non, ce n'est pas seulement une déclaration, c'est une définition (qui inclut une déclaration, bien que pas sous forme de prototype). La norme spécifie qu'une déclaration avec une liste vide d'argument et qui fait partie d'une définition spécifie que cette fonction ne prend aucun argument. C'est ce qu'on veut et cette définition ne me choc donc pas, car parfaitement valide.

Thierry

Citation:

---

Envoyé par Thierry Chappuis

La norme spécifie qu'une déclaration avec une liste vide d'argument et qui fait partie d'une définition spécifie que cette fonction ne prend aucun argument.

---

Peux tu me donner le passage de la norme qui le dit?

D'autre part, pourquoi GCC le sanctionne t'il?

D'autre part dans l'ouvrage de Achille Braquelaire, on trouve p17 :

Citation:

---

Avec les précédentes versions du langage C, la déclaration des fonctions ou des paramètres de fonction de types int était facultative. Par exemple, la déclaration "f(x){..." était équivalente à la déclaration actuelle "int f(int x){...". cette tolérance a été retirée de la norme C99.

---

Citation:

---

Envoyé par madlove40

bjr!
j'aimerais svp savoir quelle est la meilleur façon d'apprendre C pas a pas? jai lancer des recherches sur google mais souvent on tombe sur de sites qui ne sont pas destiné au vraie debutants (ce qui ne savent absolument rien de C) mais qui sont destines a ceux qui ont des notions de C ou ce qui veulent juste un petits coup de pouce.merci de m'aides svp
P.S je ne connait absolument rien a C

---

Suis les cours et tutoriels pour apprendre C et aussi la FAQ C.

Citation:

---

Envoyé par nicolas.sitbon

D'autre part dans l'ouvrage de Achille Braquelaire, on trouve p17 :

---

On est d'accord que l'indication explicite du type retourné est maintenant obligatoire. Mais tu parles de la validité de l'expression

Code:

---

1 2 3 4

int f() { }

---

La norme précise bien que lors de la définition d'une fonction (et la déclaration implicite qui en découle), les parenthèses vides constituent une indication comme quoi la fonction n'a pas de paramètres.

Par contre, cette forme de définition n'étant pas un prototype, certains compilateurs le font remarquer :

Code:

---

1 2 3 4 5 6 7 8 9 10

void f () { }   int main (void) { f (); return 0; }

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : D:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c:2: warning: function declaration isn't a prototype Linking console executable: console.exe Process terminated with status 0 (0 minutes, 0 seconds) 0 errors, 1 warnings

---

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

Code:

---

1 2 3 4 5 6 7 8 9 10

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é, mais qui est probablement une erreur de codage. (Pourquoi passer un paramètre si il n'est pas utilisé ?)

C'est pourquoi il est recommandé d'utiliser la forme prototypale :

Code:

---

1 2 3 4 5 6 7 8 9 10

void f (void) { }   int main (void) { f (123); return 0; }

---

car cette fois, le défaut est signalé par le compilateur :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Project : Forums Compiler : GNU GCC Compiler (called directly) Directory : D:\dev\forums\ -------------------------------------------------------------------------------- Switching to target: default Compiling: main.c main.c: In function `main': main.c:7: error: too many arguments to function `f' Process terminated with status 1 (0 minutes, 0 seconds) 1 errors, 0 warnings

---

Voilà pour le cas général. Concernant main(), en principe, on ne devrait pas appeler main() dans un programme, donc la forme simple main() devrait suffire et le compilateur pourrait ne rien dire. Mais le cas général semble avoir été appliqué par gcc, notamment, ce qu'il incite à utiliser la forme prototypale de main(void), ce qui est finalement une Bonne Chose.

Conclusion.

Il est tout à fait autoriser et sans danger d'utiliser main() si on est certain qu'il ne sera jamais appelé.

Il est simple et clair d'utiliser main(void), car ça couvre les cas tordus et ça fait taire le compilateur... Je recommande cette forme.

Ok, maintenant que penser de ça :

Citation:

---

Dans une définition (implémentation) :

* On peut ne pas préciser le type de retour d'une fonction. Dans ce cas celle-ci est supposée retourner un int.

---

Citation:

---

Envoyé par nicolas.sitbon

D'autre part dans l'ouvrage de Achille Braquelaire, on trouve p17 :

Citation:

---

Avec les précédentes versions du langage C, la déclaration des fonctions ou des paramètres de fonction de types int était facultative. Par exemple, la déclaration "f(x){..." était équivalente à la déclaration actuelle "int f(int x){...". cette tolérance a été retirée de la norme C99.

---

---

Citation:

---

Envoyé par nicolas.sitbon

Peux tu me donner le passage de la norme qui le dit?

---

Je te laisse fouiller...

Citation:

---

Envoyé par WG14/N1256 Committee Draft — Septermber 7, 2007 ISO/IEC 9899:TC3

6.9.1 Function definitions
Syntax
1 function-definition:
declaration-specifiers declarator declaration-listopt compound-statement
declaration-list:
declaration
declaration-list declaration
Constraints
2 The identifier declared in a function definition (which is the name of the function) shall
have a function type, as specified by the declarator portion of the function definition.141)
3 The return type of a function shall be void or an object type other than array type.
4 The storage-class specifier, if any, in the declaration specifiers shall be either extern or
static.
5 If the declarator includes a parameter type list, the declaration of each parameter shall
include an identifier, except for the special case of a parameter list consisting of a single
parameter of type void, in which case there shall not be an identifier. No declaration list
shall follow.
6 If the declarator includes an identifier list, each declaration in the declaration list shall
have at least one declarator, those declarators shall declare only identifiers from the
identifier list, and every identifier in the identifier list shall be declared. An identifier
declared as a typedef name shall not be redeclared as a parameter. The declarations in the
declaration list shall contain no storage-class specifier other than register and no
initializations.
7 The declarator in a function definition specifies the name of the function being defined
and the identifiers of its parameters. If the declarator includes a parameter type list, the
list also specifies the types of all the parameters; such a declarator also serves as a
function prototype for later calls to the same function in the same translation unit. If the
declarator includes an identifier list,142) the types of the parameters shall be declared in a
following declaration list. In either case, the type of each parameter is adjusted as
described in 6.7.5.3 for a parameter type list; the resulting type shall be an object type.
8 If a function that accepts a variable number of arguments is defined without a parameter
type list that ends with the ellipsis notation, the behavior is undefined.
9 Each parameter has automatic storage duration. Its identifier is an lvalue, which is in
effect declared at the head of the compound statement that constitutes the function body
(and therefore cannot be redeclared in the function body except in an enclosed block).
The layout of the storage for parameters is unspecified.
10 On entry to the function, the size expressions of each variably modified parameter are
evaluated and the value of each argument expression is converted to the type of the
corresponding parameter as if by assignment. (Array expressions and function
designators as arguments were converted to pointers before the call.)
11 After all parameters have been assigned, the compound statement that constitutes the
body of the function definition is executed.
12 If the } that terminates a function is reached, and the value of the function call is used by
the caller, the behavior is undefined.
13 EXAMPLE 1 In the following:
extern int max(int a, int b)
{
return a > b ? a : b;
}
extern is the storage-class specifier and int is the type specifier; max(int a, int b) is the
function declarator; and
{ return a > b ? a : b; }
is the function body. The following similar definition uses the identifier-list form for the parameter
declarations:

extern int max(a, b)
int a, b;
{
return a > b ? a : b;
}
Here int a, b; is the declaration list for the parameters. The difference between these two definitions is
that the first form acts as a prototype declaration that forces conversion of the arguments of subsequent calls
to the function, whereas the second form does not.
14 EXAMPLE 2 To pass one function to another, one might say
int f(void);
/* ... */
g(f);
Then the definition of g might read
void g(int (*funcp)(void))
{
/* ... */
(*funcp)(); /* or funcp(); ... */
}
or, equivalently,
void g(int func(void))
{
/* ... */
func(); /* or (*func)(); ... */
}

-----------
141) The intent is that the type category in a function definition cannot be inherited from a typedef:
typedef int F(void); // type F is ‘‘function with no parameters
// returning int’’
F f, g; // fand g both have type compatible with F
F f { /* ... */ } // WRONG: syntax/constraint error
F g() { /* ... */ } // WRONG: declares that g returns a function
int f(void) { /* ... */ } // RIGHT: f has type compatible with F
int g() { /* ... */ } // RIGHT: g has type compatible with F
F *e(void) { /* ... */ } // e returns a pointer to a function
F *((e))(void) { /* ... */ } // same: parentheses irrelevant
int (*fp)(void); // fp points to a function that has type F
F *Fp; //Fp points to a function that has type F
142) See ‘‘future language directions’’ (6.11.7).
142 Language §6.9.1

---

(pour plus de clarté, j'ai déplacé les notes de bas de page à la fin...)

Citation:

---

Envoyé par nicolas.sitbon

Ok, maintenant que penser de ça :

---

Que le document cité concerne C90...

Citation:

---

Envoyé par Emmanuel Delahaye

Que le document cité concerne C90...

---

D'accord, maintenant quel comportement doit on avoir dans ce cas là?
Je veux dire par là, quel version de la norme fait autorité?

Citation:

---

Envoyé par nicolas.sitbon

D'accord, maintenant quel comportement doit on avoir dans ce cas là?
Je veux dire par là, quel version de la norme fait autorité?

---

Celle que tu choisis d'utiliser.

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.

Citation:

---

Envoyé par Thierry Chappuis

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:

---

1 2 3

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

---

Citation:

---

Envoyé par Emmanuel Delahaye

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

Code:

---

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

Citation:

---

Envoyé par c-candide

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

---

OK, le comportement est indéterminé.

Citation:

---

Envoyé par c-candide

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

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

Citation:

---

Envoyé par Emmanuel Delahaye

En effet, il est techniquement possible de coder :

Code:

---

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:

---

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.

Citation:

---

Envoyé par c-candide

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() :aie:).

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 :

Citation:

---

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:

---

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.

Citation:

---

Envoyé par Melem

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

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 ?

Citation:

---

Envoyé par Melem

Code:

---

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.

Citation:

---

Envoyé par Melem

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.

Citation:

---

Envoyé par 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 ?

---

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

Thierry

Citation:

---

Envoyé par 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.

---

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

Citation:

---

Envoyé par Melem

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 !

Citation:

---

Envoyé par Melem

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.

Citation:

---

Envoyé par Thierry Chappuis

A la page 7, on a:

Code:

---

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.

Citation:

---

Envoyé par nicolas.sitbon

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

Citation:

---

Envoyé par Thierry Chappuis

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.

Citation:

---

Envoyé par c-candide

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

Citation:

---

Envoyé par c-candide

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 ?

Au risque de me fair crier dessus:aie: 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.

Citation:

---

Envoyé par snake264

Au risque de me fair crier dessus:aie: 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.

Roo je m'exprime si mal que sa:mrgreen: 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.

Citation:

---

Envoyé par snake264

Roo je m'exprime si mal que sa:mrgreen: 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

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.