Pour que le compilateur puisse compiler les fichiers séparément, il faut que vous respectiez les conditions suivantes :
Ces conditions ont des répercussions sur la syntaxe des programmes. Elles seront vues dans les paragraphes suivants.
Déclaration des types.
Les types doivent toujours être définis avant toute utilisation dans un fichier source. Par exemple, il est interdit d'utiliser une structure client sans l'avoir définie avant sa première utilisation. Toutefois, il est possible d'utiliser un pointeur sur un type de donnée sans l'avoir complètement défini. Une simple déclaration du type de base du pointeur suffit en effet dans ce cas là. De même, un simple class MaClasse suffit en C++ pour déclarer une classe sans la définir complètement.
Déclaration des variables.
Les variables qui sont définies dans un autre fichier doivent être déclarées avant leur première utilisation. Pour cela, on les spécifie comme étant des variables externes, avec le mot clé extern :
 extern int i; /* i est un entier qui est déclaré et
 créé dans un autre fichier.
 Ici, il est simplement déclaré.
Inversement, si une variable ne doit pas être accédée par un autre module, il faut déclarer cette variable statique. Ainsi, même si un autre fichier utilise le mot clé extern, il ne pourra pas y accéder.
Déclaration des fonctions.
Lorsqu'une fonction se trouve définie dans un autre fichier, il est nécessaire de la déclarer. Pour cela, il suffit de donner sa déclaration (le mot clé extern est également utilisable, mais facultatif dans ce cas) :
 int factorielle(int);
 factorielle est une fonction attendant comme paramètre
 un entier et renvoyant une valeur entière.
 Elle est définie dans un autre fichier.
Les fonctions inline doivent impérativement être définies dans les fichiers où elles sont utilisées, puisqu'en théorie, elles sont recopiées dans les fonctions qui les utilisent. Cela implique de placer leur définition dans les fichiers d'en-tête .h ou .hpp. Comme le code des fonctions inline est normalement inclus dans le code des fonctions qui les utilisent, les fichiers d'en-tête contenant du code inline peuvent être compilés séparément sans que ces fonctions ne soient définies plusieurs fois. Par conséquent, l'éditeur de liens ne générera pas d'erreur (alors qu'il l'aurait fait si on avait placé le code d'une fonction non inline dans un fichier d'en-tête inclus dans plusieurs fichiers sources .c ou .cpp). Certains programmeurs considèrent qu'il n'est pas bon de placer des définitions de fonctions dans des fichiers d'en-tête, il placent donc toutes leurs fonctions inline dans des fichiers portant l'extension .inl. Ces fichiers sont ensuite inclus soit dans les fichiers d'en-tête .h, soit dans les fichiers .c ou .cpp qui utilisent les fonctions inline.
Directives d'édition de liens.
Le langage C++ donne la possibilité d'appeler des fonctions et d'utiliser des variables qui proviennent d'un module écrit dans un autre langage. Pour permettre cela, il dispose de directives permettant d'indiquer comment l'édition de liens doit être faite. La syntaxe permettant de réaliser cela utilise le mot clé extern, avec le nom du langage entre guillemets. Cette directive d'édition de liens doit précéder les déclarations de variables et de données concernées. Si plusieurs variables ou fonctions utilisent la même directive, elles peuvent être regroupées dans un bloc délimité par des accolades, avec la directive d'édition de liens placée juste avant ce bloc. La syntaxe est donc la suivante :
 extern "langage" [déclaration | {
 déclaration
 }]
Cependant, les seuls langages qu'une implémentation doit obligatoirement supporter sont les langages « C » et « C++ ». Pour les autres langages, aucune norme n'est définie et les directives d'édition de liens sont dépendantes de l'implémentation.
Exemple 6-4. Déclarations utilisables en C et en C++.
 #ifdef __cplusplus
 extern "C"
 #endif
 extern int EntierC;
 int FonctionC(void);
 #ifdef __cplusplus
 #endif
Dans l'exemple précédent, la compilation conditionnelle est utilisée pour n'utiliser la directive d'édition de liens que si le code est compilé en C++. Si c'est le cas, la variable EntierC et la fonction FonctionC sont déclarées au compilateur C++ comme étant des objets provenant d'un module C.

Programmation C-C++/Écrire du code illisible

Il est facile, très facile, de faire des programmes illisibles en C ou en C++. Il existe même un concours du code le plus obscur ! Cela dit, deux choses peuvent être dites à ce propos :
Si vous voulez malgré tout vous amuser, voici quelques conseils utiles :
Exemple 7-1. Programme parfaitement illisible.
/* Que fait ce programme ? */
int main(void)
int zkmlpf,geikgh,wdxaj;
 scanf("%u",&zkmlpf);for (wdxaj=0,
 geikgh=0;
 ((wdxaj+=++geikgh),geikgh)<zkmlpf;);
 printf("%u",wdxaj); return 0;
Vous l'aurez compris : il est plus simple de dire ici ce qu'il ne faut pas faire que de dire comment il faut faire. Je ne prétends pas imposer à quiconque une méthodologie quelconque, car chacun est libre de programmer comme il l'entend. En effet, certaines conventions de codages sont aussi absurdes qu'inutiles et elles ont l'inconvénient de ne plaire qu'à celui qui les a écrites (et encore...). C'est pour cette raison que je me suis contenté de lister les sources potentielles d'illisibilité des programmes. Sachez donc simplement que si vous utilisez une des techniques données dans ce paragraphe, vous devriez vous assurer que c'est réellement justifié et revoir votre code. Pour obtenir des programmes lisibles, il faut simplement que chacun y mettre un peu du sien, c'est aussi une marque de politesse envers les autres programmeurs.

Livre de cuisine/Ruifard de Valbonnais
Le " ruifar de Valbonnais ", est un dessert isérois se presentant sous la forme d'une tourte fourré au pommes rouges de la région de Valbonnais.

Conseils de codage en C/Sécurité
L'application des conseils suivants rendent les logiciels plus sécurisés : moins vulnérables aux attaques.
Pas d'affichage direct (c_sec_1).
Il faut éviter d'afficher une chaîne provenant de l'utilisateur (argument de programme, de fonction, contenu d'un fichier) en l'employant comme premier argument des fonctions codice_1.
Justification.
Améliorer la sécurité en évitant le plantage du programme.
Exemple.
Le mauvais exemple :
/* prog.c */
int main(int argc, char** argv)
 if (argc > 1)
 printf(argv[1]); // afficher le premier argument
 return EXIT_SUCCESS;
Que va-t'il se passer si l'on tape la commande suivante :
 prog "Exemple : %s"
L'argument pour le %s n'étant pas fourni explicitement, le programme risque d'afficher le contenu de la mémoire à une adresse indéfinie, voire retourner une erreur de segmentation.
Le bon exemple :
/* prog.c */
int main(int argc, char** argv)
 if (argc > 1)
 (void)printf("%s", argv[1]); // afficher le premier argument
 return EXIT_SUCCESS;
Si l'on tape la commande suivante :
 prog "Exemple : %s"
Le programme affiche littéralement :
 Exemple : %s
Cacher les mots de passe (c_sec_2).
Lorsqu'un programme a besoin d'un mot de passe saisi par l'utilisateur, que ce soit par l'interface graphique, ou par une console texte, la saisie ne doit pas être faite en clair.
Il faut :
Justification.
Améliorer la sécurité en évitant que les mots de passe d'un utilisateur ne soient visibles aux autres (poste public, lieu de travail, ...), et éviter une opération intempestive de presse papier contenant le mot de passe (envoi d'une copie d'écran par exemple).
Outil.
Certaines librairies graphiques possèdent des champs de saisie spéciaux pour les mots de passe, d'autres librairies possèdent des fonctions de saisie de mots de passe sur la console.
Pour la saisie par console, si aucune fonction spéciale existe, il faut désactiver l'affichage de la saisie tant que l'utilisateur n'a pas fini sa saisie.

Vocabulaire de base du japonais
Japonais/Vocabulaire/Temps
Japonais/Vocabulaire/Désignation des personnes

Japonais/Vocabulaire/Métiers
Photographie/Personnalités/B/Ludivine Bouille