Discussion :

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

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

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

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

[foetus]

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

Déjà renseigne-toi

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

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

Pour des pistes de réflexion :

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

[n5Rzn1D9dC]

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 ^

[chrtophe]

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 /* */ à //.

[n5Rzn1D9dC]

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

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

[Bousk]

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 ?

[n5Rzn1D9dC]

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

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

[n5Rzn1D9dC]

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

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

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

[n5Rzn1D9dC]

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

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)

[foetus]

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

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

[chrtophe]

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.

[n5Rzn1D9dC]

Ok merci bien pour cette explication explicite.

[moldavi]

Bonjour.

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 :

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

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à /**/.

[jo_link_noir]

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.

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.

[moldavi]

Bonjour.

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.

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

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.

[foetus]

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

[moldavi]

Bonjour.

Je l'ai dit avant 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

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