Les commentaires en cpp

Salut,

Je débute en cpp, je n'ai encore écrit aucun programme mais je fouillais dans les librairies et en particulier stdio.h et là je suis tombé sur un fichier qui contient des commentaires en C et d'autres en Cpp..
Pourquoi ??

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

// // stdio.h // // Copyright (c) Microsoft Corporation. All rights reserved. // // The C Standard Library <stdio.h> header. // #pragma once #ifndef _INC_STDIO // include guard for 3rd party interop #define _INC_STDIO   #include <corecrt.h> #include <corecrt_wstdio.h>   _CRT_BEGIN_C_HEADER   /* Buffered I/O macros */   #define BUFSIZ 512       /*  * Default number of supported streams. _NFILE is confusing and obsolete, but  * supported anyway for backwards compatibility.  */ #define _NFILE _NSTREAM_   #define _NSTREAM_ 512

---

Pourquoi mélangent-ils des commentaires C avec des commentaires Cpp ?
Je préfère poser la question avant de poursuivre mon apprentissage car ça me parait important de connaitre la raison.

Merci

Bonjour,

Ces deux types de commentaires sont valides en C et en C++

Je ne vois pas où tu a trouvé que ce n'est pas le cas.

:)

Citation:

---

Envoyé par n5Rzn1D9dC

Pourquoi mélangent-ils des commentaires C avec des commentaires Cpp ?

---

Déjà renseigne-toi :whistle: :aie:

Le C autorise les commentaires // 1 commentaire depuis la norme C99, soit depuis 21 ans :mouarf:

Après pour faire 1 réponse de Normand : en quoi mélanger les 2 types de commentaires est en soi gênant :koi: ?

Pour des pistes de réflexion :mrgreen: :

• L'entête du fichier doit être 1 entête "injectée" dans le source pour y présenter le nom et le copyright (entre autres). Et effectivement, c'est souvent avec des commentaires 1 ligne //. En fait je ne sais pas :koi: Moi, je ne mets jamais d'entête lorsque l'IDE ne me force pas la main. C'est pour moi assez inutile, et j'ai 1 prénom avec 1 accent, donc pas compatible ASCII :aie:
• Les autres commentaires ressemblent à des commentaires Doxygen, mais ce serait plus /** que /*. Peut-être que Doxygen, ou 1 autre générateur de documentation, passe quand même :koi:

Citation:

---

Envoyé par droggo

Bonjour,

Ces deux types de commentaires sont valides en C et en C++

Je ne vois pas où tu a trouvé que ce n'est pas le cas.

:)

---

Je n'ai jamais dit que ce n'était pas autorisé, c'est juste que je trouve cela étrange de mélanger deux type de commentaires différents. Je n'en vois pas l'intérêt..
edit: Je ne comprend pas pourquoi le mec qui a créé le fichier s'est dit à un moment "oh tient là jvais mettre en commentaire C" "Et puis là jvais en mettre un en cpp". C'est pas homogène..
Enfin, merci quand même pour vos réponses ^

Citation:

---

Je ne comprend pas pourquoi le mec qui a créé le fichier s'est dit à un moment "oh tient là jvais mettre en commentaire C" "Et puis là jvais en mettre un en cp

---

Il ne s'agit pas de commentaires C et CPP, mais des commentaires utilisés en C et/ou en CPP (comme déjà dit). Ni le C ni le CPP n'utilise sa propre notation.

Sur un fichier comme stdio.h, il y aura eu certainement plusieurs intervenants, dont certains préférant la notation /* */ à //.

Citation:

---

Envoyé par chrtophe

Il ne s'agit pas de commentaires C et CPP, mais des commentaires utilisés en C et/ou en CPP (comme déjà dit). Ni le C ni le CPP n'utilise sa propre notation.

Sur un fichier comme stdio.h, il y aura eu certainement plusieurs intervenants, dont certains préférant la notation /* */ à //.

---

C'est pas ce que dit ce mec: http://casteyde.christian.free.fr/cp...line/c207.html

Citation:

---

1.1. Les commentaires en C++

Les commentaires sont nécessaires et très simples à faire. Tout programme doit être commenté. Attention cependant, trop de commentaires tue le commentaire, parce que les choses importantes sont noyées dans les banalités.

Il existe deux types de commentaires en C++ : les commentaires de type C et les commentaires de fin de ligne (qui ne sont disponibles qu'en C++).

Les commentaires C commencent avec la séquence barre oblique - étoile. Les commentaires se terminent avec la séquence inverse : une étoile suivie d'une barre oblique.

Exemple 1-1. Commentaire C

/* Ceci est un commentaire C */

Ces commentaires peuvent s'étendre sur plusieurs lignes.

En revanche, les commentaires de fin de lignes s'arrêtent à la fin de la ligne courante, et pas avant. Ils permettent de commenter plus facilement les actions effectuées sur la ligne courante, avant le commentaire. Les commentaires de fin de ligne commencent par la séquence constituée de deux barres obliques (ils n'ont pas de séquence de terminaison, puisqu'ils ne se terminent qu'à la fin de la ligne courante). Par exemple :

Exemple 1-2. Commentaire C++

action quelconque // Ceci est un commentaire C++
action suivante

---

Bah ce cours est pourri ou obsolète depuis 20 ans.
Et quand je vois que l'exemple de programme est... strictement du C, je penche sur le premier.
Les commentaires, en C et en C++ peuvent s'écrire // et s'étendre sur toute la ligne ou /* et s'arrêter au prochain */
On vient de le répéter 5 fois, est-ce suffisant ?:weird:

Si ce cours est pourrit, bah enlevez-le de la première page de vos cours en cpp :aie:
https://cpp.developpez.com/cours/cpp/

Le document date de 2008, il n'est pas à jour.

Si tu débutes en cpp, déjà n’étudie pas l'en-tête stdio.h qui est du C.

D'autre part, tu as d'autres choses à te focaliser que la notation des commentaires.

Citation:

---

Envoyé par chrtophe

Le document date de 2008, il n'est pas à jour.

Si tu débutes en cpp, déjà n’étudie pas l'en-tête stdio.h qui est du C.

D'autre part, tu as d'autres choses à te focaliser que la notation des commentaires.

---

Oué mais moi j'aime bien que les choses soit claire dès le début. J'ai commencé le coding par l'assembleur avec Fasm et il n'y a pas 36 façon de faire un commentaire, c'est ; point barre.|
Je n 'aime pas les choses qui partent dans toutes les directions en même temps...

Ça fait un moment que les commentaires du style C++ sont dans la norme C: https://en.cppreference.com/w/c/comment

Pour les cours, tu peux plus ou moins jeter tout ce qui est avant 2011 et prendre un cours qui enseigne avec C++14, C++17 ou, si cela existe, C++20.

Ceux qui enseignent C/C++ sont aussi à éviter: ce ne sont ni des cours de C, ni cours de C++.

Citation:

---

Envoyé par jo_link_noir

Ça fait un moment que les commentaires du style C++ sont dans la norme C: https://en.cppreference.com/w/c/comment

Pour les cours, tu peux plus ou moins jeter tout ce qui est avant 2011 et prendre un cours qui enseigne avec C++14, C++17 ou, si cela existe, C++20.

---

Perso je trouve ça idiot de mélanger les commentaires de style C avec les commentaires de style C++. Mais bon si c'est comme ça, tant pis, jvais faire avec.

Citation:

---

Ceux qui enseignent C/C++ sont aussi à éviter: ce ne sont ni des cours de C, ni cours de C++.

---

Ba ouais ba faudra dire au modo qu'il supprime le cours de ChristianCasteyde qui est mis en page principale des cours de cpp.... (et qui mélange les deux types)

Citation:

---

Envoyé par n5Rzn1D9dC

Oué mais moi j'aime bien que les choses soit claire dès le début. J'ai commencé le coding par l'assembleur avec Fasm et il n'y a pas 36 façon de faire un commentaire, c'est ; point barre.|
Je n 'aime pas les choses qui partent dans toutes les directions en même temps...

---

Si tu pètes 1 plomb pour les commentaires, arrête tout de suite le C/ C++ :aie: :aie: - parce que'avec le "C with classes", les macros qui permettent de coder des fois salement, les "templates" (je pense au mot clef typename), ceux qui n'utilisent pas la STL (ou pas totalement), ... faire du code "carré" et n'avoir qu'1 façon de coder :ptdr: :ptdr: Le C++ étant 1 surcouche objet du C

Ou alors comme le dit @jo_link_noir, commence directement à partir du C++17 ou C++20 :mrgreen:

Citation:

---

Envoyé par n5Rzn1D9dC

Ba ouais ba faudra dire au modo qu'il supprime le cours de ChristianCasteyde qui est mis en page principale des cours de cpp.... (et qui mélange les deux types)

---

À sa décharge :whistle:, lorsqu'il dit commentaire C et commentaire C++, ce sont plus des noms. Parce qu'effectivement le commentaire 1 ligne // est apparu avec le C++ donc commentaire C++.
L'autre commentaire /* */ vient du C.

Citation:

---

Ba ouais ba faudra dire au modo qu'il supprime le cours de ChristianCasteyde qui est mis en page principale des cours de cpp.... (et qui mélange les deux types)

---

Le cours n'est pas à jour par rapport aux dernières normes, ce n'est pas pour ça qu'il est à jeter, il reste globalement valable.

Par contre, il mélange le C et le C++, mais en annonçant la couleur dans le titre.

Un cours mélangeant le C et le C++ peut t’emmêler les pinceaux, c'est pour ça que c'est en général déconseillé, car si tu commences le C avant le C++, lors de l'apprentissage C++ , certains éléments devront être repris à zéro. a la base C++ était au niveau compilation une extension du C.
Ce qui peut être fait en C le sera en C++, mais avec des outils souvent plus pratiques/efficaces.

En gros, on utilise le C pour la programmation système, le C++ pour le reste, mais tu peux déroger à cette règle, rien ne t'empêche de faire de la programmation orientée objet en C, mais tu devras réinventer la roue.

Ok merci bien pour cette explication explicite.

Bonjour.

Citation:

---

Envoyé par n5Rzn1D9dC

Salut,

Je débute en cpp, je n'ai encore écrit aucun programme mais je fouillais dans les librairies et en particulier stdio.h et là je suis tombé sur un fichier qui contient des commentaires en C et d'autres en Cpp..
Pourquoi ??

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

// // stdio.h // // Copyright (c) Microsoft Corporation. All rights reserved. // // The C Standard Library <stdio.h> header. // #pragma once #ifndef _INC_STDIO // include guard for 3rd party interop #define _INC_STDIO   #include <corecrt.h> #include <corecrt_wstdio.h>   _CRT_BEGIN_C_HEADER   /* Buffered I/O macros */   #define BUFSIZ 512       /*  * Default number of supported streams. _NFILE is confusing and obsolete, but  * supported anyway for backwards compatibility.  */ #define _NFILE _NSTREAM_   #define _NSTREAM_ 512

---

Pourquoi mélangent-ils des commentaires C avec des commentaires Cpp ?
Je préfère poser la question avant de poursuivre mon apprentissage car ça me parait important de connaitre la raison.

Merci

---

C'est vrai que ce mélange est débile ici, et que cela manque de rigueur.

Tu viens de comprendre pourquoi beaucoup de programme ont des bugs. Le manque de rigueur selon moi. Et c'est déjà visible dans les commentaires.

J'utilise les deux, mais de manière cohérente :

/* Buffered I/O macros */

Là je vais mettre :

// Buffered I/O macros

Il n'y a qu'une ligne.

Si plusieurs lignes, alors /**/, même si des fois, cela pose problème avec du code qui contient déjà /**/.

Citation:

---

Envoyé par moldavi

C'est vrai que ce mélange est débile ici, et que cela manque de rigueur.

---

Pourtant les commentaires sont utilisés de manière cohérente ici: // pour les en-têtes de fichier / copyright /* */ pour les commentaires de code.

Citation:

---

Envoyé par moldavi

J'utilise les deux, mais de manière cohérente

---

On peut aussi dire qu'utiliser les 2 syntaxes pour commenter le code est incohérent, quelle que soit la justification derrière.

Le but est surtout d'avoir une logique qui tienne la route et reste consistante (et donc cohérent), mais ce n'est pas parce qu'une chose ne semble pas l'être au premier abord qu'elle ne suit pas une règle bien définie.

Bonjour.

Citation:

---

Envoyé par jo_link_noir

Pourtant les commentaires sont utilisés de manière cohérente ici: // pour les en-têtes de fichier / copyright /* */ pour les commentaires de code.

---

En effet, vu comme cela, il y a une logique. Pourtant ni n5Rzn1D9dC ne l'a vu, d'où sa question, ni moi. Cela pose question non ? C'est pareil dans tous les .h ?

Quand je vois /* Buffered I/O macros */, je sais que niveau rigueur et choix cohérent, c'est mort :

// Buffered I/O macros

suffit lorsque tu mélanges les genres. Il n'y a qu'une seule ligne à commenter.

Citation:

---

Envoyé par jo_link_noir

On peut aussi dire qu'utiliser les 2 syntaxes pour commenter le code est incohérent, quelle que soit la justification derrière.

---

Oui c'est vrai. Mais lorsque l'on code tous les jours, on voit le côté pratique.

Si j'ai une seule ligne de code à commenter, j'utilise //

Si j'ai plusieurs lignes à commenter, j'utilise /**/.

Des fois, c'est plus compliqué.

Citation:

---

Envoyé par jo_link_noir

Le but est surtout d'avoir une logique qui tienne la route et reste consistante (et donc cohérent), mais ce n'est pas parce qu'une chose ne semble pas l'être au premier abord qu'elle ne suit pas une règle bien définie.

---

Si tous les headers de type stdio.h, suivent cette logique, je serai s'accord. Même si je la trouve débile.

Citation:

---

Envoyé par moldavi

Si tous les headers de type stdio.h, suivent cette logique, je serai s'accord. Même si je la trouve débile.

---

Je l'ai dit avant :mrgreen: lorsque tu utilisais Visual C++, à chaque fois que tu ajoutes un fichier .h ou une unité, automatiquement il te rajoute cette entête qui contient ton nom, prénom, société/ copyright/ licence, le nom de l'unité, ...
Tout cela est configurable dans l'IDE.

Je dis "utilisais" parce que je ne sais pas si Visual C++ le fait encore et il me semble qu'1 partie des IDE le faisaient fin 90 - début 2000.
Et en 2012 j'ai utilisé XCode 4 qui le faisait également :whistle:

Bonjour.

Citation:

---

Envoyé par foetus

Je l'ai dit avant :mrgreen: lorsque tu utilisais Visual C++, à chaque fois que tu ajoutes un fichier .h ou une unité, automatiquement il te rajoute cette entête qu contient ton nom, prénom, société/ copyright/ licence, le nom de l'unité, ...
Tout cela est configurable dans l'IDE.

Je dis "utilisais" parce que je ne sais pas si Visual C++ le fait encore et il me semble qu'1 partie des IDE le faisaient fin 90 - début 2000.
Et en 2012 j'ai utilisé XCode 4 qui le faisait également :whistle:

---

Je n'ai rien compris à votre intervention. Etes-vous en France, vu qu'il est 5 heures du mat ?

Citation:

---

Envoyé par moldavi

Je n'ai rien compris à votre intervention.

---

Il faut utiliser 1 IDE pour cela :mrgreen:
Utilise ton moteur de recherche préféré pour rechercher "File Header Comment" :google: (<- moi je trouve des add-ins Visual pour le faire)
Donc oui, pour ces commentaires, ils ont tous la même forme :mrgreen:

Voici 2 exemples :

• Add document header for files automatically in Visual Studio, lien en anglais
• Header Comment Visual Studio AddIn for C#, lien codeproject.com en anglais

Salut,

Ce qu'il faut savoir, c'est que les développeurs aiment bien fournir des informations "utiles" aux gens qui liront leur code, ne serait-ce que pour leur permettre de comprendre le code qu'ils ont écrit.

On peut scinder ces informations en deux grandes catégories (il y a d'autres classifications possibles, celle-ci est celle qui nous intéressera le plus ;) ):

D'un coté, on a des informations "générales" qui sont, à de très rares points de variation (comme la date à laquelle le fichier a été créé ou le nom du fichier), toujours les mêmes de fichier en fichier. Elles peuvent contenir (sans être exhaustif)

• le nom et l'adresse à laquelle contacter l'auteur du fichier
• un rappel de la licence sous laquelle le fichier est fourni
• un rappel du projet dont le fichier fait partie
• le numéro de version du fichier
• j'en passe, et de meilleures

Et, de l'autre, nous aurons des informations plus "fonctionnelles", qui décrivent les différentes fonctionnalités fournies par le fichier que le lecteur a devant les yeux.

Ces informations sont, bien sur, spécifiques à chaque fichiers, mais elles seront, malgré tout, toujours structurées de manière sensiblement identique. Par exemple, nous pourrions décrire une classe en fournissant

• une description succincte de l'objectif poursuivi la classe
• l'énoncé du besoin qui a mené à la création de la classe
• les invariants qui composent cette classe
• les "cas d'utilisation" dans lesquels cette classe sera utile
• les différences qui existent (éventuellement) entre cette classe bien particulière et d'autres classes qui pourraient avoir sensiblement le même objectif
• j'en passe et de meilleures

De même, nous pourrions décrire une fonction (qu'il s'agisse de la fonction membre d'une classe ou d'une fonction libre) en fournissant

• une brève description de ce que fait la fonction
• une description des différents paramètres dont la fonction a besoin pour travailler
• une description de la valeur de retour qu'elle est sensée renvoyer (s'il y en a une)
• les pré conditions qui doivent être respectées pour que la fonction puisse travailler
• les post conditions que la fonction devra respecter pour que l'on puisse considérer son résultat comme "cohérent"
• les exceptions qui pourraient être lancées si le comportement ne peut pas être considéré comme "cohérent"
• j'en passe et de meilleures

D'un autre coté, il faut savoir que les développeurs sont, aussi, très souvent très fainéants et que c'est "assez ch...ant" que de devoir réécrire toujours sensiblement la même chose.

C'est la raison pour laquelle la plupart des éditeurs de texte (ou des EDI) que l'on va utiliser vont nous permettre de créer des "modèles" pour ces différentes informations (et, même, de créer des modèles pour une quantité impressionnante d'éléments qui auront tendance à revenir sans cesse) que l'on peut -- a priori -- configurer "selon notre bon vouloir", selon nos propres besoins.

Si bien que, au lieu de devoir réécrire toutes ces informations dans chaque fichier, pour chaque fonctionnalité exposée dans un fichier, nous "n'aurons qu'à" utiliser un raccourcis, une séquence bien particulière de touches pour que l'éditeur de texte ajoute automatiquement le modèle de "code" que l'on a créé à l'endroit où se trouve le curseur; de manière à ce que l'on n'ait plus qu'à modifier les différents point de variation.

Pour le reste, il faut savoir que les commentaires sont, purement et simplement, totalement ignorés en C et en C++. La forme que l'on va leur donner n'a donc de l'intérêt que pour la personne qui va les écrire et -- peut être -- pour la personne qui lira le fichier.

Il se peut donc que la personne qui écrit un fichier ait certaines "habitudes", qu'elle ait une certaine vision de la manière dont les commentaires doivent être organisés et représentés. Ce sera forcément un choix tout à fait personnel, voire, un choix imposé afin d'assurer la cohérence du code au travers d'un projet.

Ce qu'il faut savoir, c'est que l'on peut, bien sur, être d'accord (ou non) avec les choix qui auront été faits, mais qu'il ne nous appartient absolument pas de remettre ces choix en question ;)

Ainsi, l'auteur d'un fichier pourrait très bien avoir décidé que, afin d'assurer une "certaine cohérence" au niveau des commentaires, les commentaires d'ordre général seront systématiquement présentés à l'aide des symboles // et que les commentaires présentant les fonctionnalités exposées par le fichier seront systématiquement créés à l'aide des commentaire multilignes /* ... */

Au final, cela pourrait donc donner un code qui ressemblerait à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

// nom_du_fichier <chemin>/nom_du_fichier // auteur: <nom> <prenom> <adresse mail> // date: DD/JJ/AAA // version 1.0.0 // <breve description du fichier> // // Ce fichier fait partie de la bibliothèque <nom du projet> // et est fourni sous licence <licence d'utilisation> // reportez vous au fichier LICENSE pour plus d'informations   /* <breve description de classe>  *  * <description du besoin>  *  * <intérêt de la classe>  *  * ...  */ class MaClasse{ public: /* <brève description de la fonction>   *   * <raison de l'existence de cette fonction>   *   * <description du premier paramètre>   * <description du deuxième paramètre>   * renvoie <telle valeur> si <condition>, <telle autre valeur> dans le cas contraire   * <pré condition à respecter lors de l'appel>   * <post condition à respecter après exécution>   * <exception lancée en cas de problème>   */ Type maFonctionQuiFaitBooh(Type2 param1, Type3 param2); /* et ainsi de suite */ };

---

Cette manière de présenter les choses en vaut largement une autre. Et, comme le compilateur ne fera absolument pas attention à tous ces commentaires, leur organisation et leur "aspect visuel" n'aura absolument aucune incidence sur le code en lui-même ;)

On parle ici de stdio.h, un fichier qui a pu être écrit par des dizaines de personnes pendant des années.

Difficile de forcer autant de personnes à utiliser le même style de commentaires, avec des règles de codage qui ont certainement évoluées dans avec le temps.

Il est possible qu'au début de l'écriture de ce fichier, seul un type de commentaire était supporté. Quand l'autre type a été autorisé, il n'était pas question de changer les anciens commentaire juste pour aligner des styles.

Aussi, il est possible que ce fichier soit en partie généré, assemblant des morceaux de code de différentes sources.

Conclusion : ce n'est vraiment pas le genre de fichiers à prendre en exemple.....et pas uniquement sur les commentaires !

Citation:

---

Envoyé par Bktero

On parle ici de stdio.h, un fichier qui a pu être écrit par des dizaines de personnes pendant des années.

---

Même pas en fait. C'est UNE implémentation de stdio.h. Celle que j'utilise (glibc) n'a que des commentaires au format /* ... */.

Citation:

---

Envoyé par SimonDecoline

Même pas en fait. C'est UNE implémentation de stdio.h. Celle que j'utilise (glibc) n'a que des commentaires au format /* ... */.

---

As tu un change log git, mercurial, ou autre à ta disposition pour affirmer cela:question:

Ou, peut-être, peux tu l'affirmer parce que tu es l'auteur du fichier, et que tu es le seul à y avoir apporté des modifications :question:

stdio.h fait partir de la bibliothèque standard du C depuis quoi? cinquante ans :question: Du moins, peut on imaginer qu'un fichier qui fournit des entrée sortie standard pour un langage (quel qu'il soit) existe -- a priori -- depuis presque aussi longtemps que le langage en lui-même, ne crois tu pas?

Alors, tu as raison sur un point: chaque compilateur, chaque fournisseur de libC va fournir sa propre écriture du fichier stdio.h. Cela ne veut pas dire qu'il n'y a eu qu'un seul auteur, ou qu'il n'a pas évolué (ou que les règles de codage en vigueur dans l'équipe qui s'occupe d'implémenter la biliothèque n'aient pas évolué) depuis qu'il a été écrit la première fois ;)

Edit:
Pour ma part, j'ai trouvé l'historique (git) du fichier de stdio.h pour la glibc ==>ICI<==, et j'ai rapidement compté:

Entre le premier avril 2011 et le cinq juin 2018, il n'y a pas eu moins de 35 commits sur ce fichier que l'on aurait pourtant pu croire particulièrement stable, et il y a eu au moins huit auteurs différents pour les commits.

Citation:

---

Envoyé par koala01

As tu un change log git, mercurial, ou autre à ta disposition pour affirmer cela...

---

Je répondais à la remarque qui disait en gros que "le fichier stdio.h n'est pas un bon exemple de commentaires homogènes" en précisant que "stdio.h" n'a pas qu'une implémentation et que certaines implémentations ont des commentaires homogènes. Si tu ne me crois pas, tu peux vérifier par toi-même en récupérant les sources (https://www.gnu.org/software/libc/sources.html) et en faisant un find glibc-2.31/ -name stdio.h -exec grep "//" {} \;.