Entrée intéressante.
Ma remarque, c’est que ça fait un peu trop exposé et pas assez FAQ. Ton entrée doit répondre aux problèmes des Zéros, qui sont principalement liés au non-vidage des tampons associés aux flux d’entrée. Il faut donc revoir le titre comme tu le dis, l’intro aussi, et insister davantage sur les problèmes possibles et leur source.
Dans le code à la fin, je pense que tu peux virer le //C99 et le inline. Le but est de rendre le code le plus accessible possible, pas de le faire ultra-performant (d’autant plus que le compilateur peut décider de lui-même d’inliner l’appel à une fonction, même sans le mot-clef). Et pourquoi utilises-tu le français pour « purger », et l’anglais pour « read » ?
J'utilise rarement ces modes, de par les comportements étranges qui y sont associés et nécessaires. Ça permet de préciser un peu mes propos, merci.
Tu as raison de ne pas les utiliser, mais comme le cours de M@teo utilise le r+ alors beaucoup de zéros l'utilisent.
Sinon je pense que ce sera difficile de parler de tout ça avec un vocabulaire plus simple et surtout sans être dans l'information incomplète ou approximative.
Sinon comme titre je vois bien quelque chose du genre : mon printf ne s'affiche pas sur le terminal, pourquoi ?
Mais à ce moment il faut reformuler l'introduction.
Je trouve également l'entrée intéressante, mais un peu compliquée. Je propose la version suivante, un peu simplifiée (il faudrait juste parler des flux standard en plus) :
Citation
[1][8] Que sont les tampons ? Comment les manipuler ?
En informatique, la lecture et l'écriture de données sur un disque dur prends un temps assez important. Afin d'éviter cette problématique, il existe en C un tampon qui est associé à chaque flux (une structure FILE si vous préférez). Ce tampon n'est rien d'autre qu'une zone mémoire d'une certaine taille dans laquelle vont être stockés les données devant être lues ou écrites sur le disque dur. Ainsi, au lieu de sollicité le disque dur pour lire ou écrire un caractère à la fois (ce qui est très lent), il ne sera appelé que lorsque le tampon sera vide (pour une lecture) ou plein (pour une écriture).
Un flux peut disposer de trois types de tampons :
non mémorisé: le flux ne dispose pas d'un tampon;
mémorisé par ligne : le tampon est remplit ou vidé lorsqu'un caractère de fin de ligne est rencontré;
pleinement mémorisé : le tampon est remplit ou vidé lorsqu'il est vide ou plein;
Il est possible de modifier le type et la taille du tampon associé à un flux à l'aide de la fonction standard setvbuf (déclarée dans l'en-tête stdio.h). Voici son prototype :
int setvbuf(FILE *stream, char *buf, int mode, size_t size);
Où stream est le flux concerné, buf le nouveau tampon, size la taille de celui-ci et mode le type de tampon. mode est spécifié par une des constantes suivantes :
_IONBF : non mémorisé.
_IOLBF : mémorisé par lignes.
_IOFBF : pleinement mémorisé.
Si buf est nul le tampon sera alloué par la fonction et sera de taille "size".
N'essayez pas d'accéder au contenu du tampon ! Ce dernier est indéterminé et vous pourriez dès lors rencontré des erreurs.
Il arrive parfois que l'on ait besoin de vider ou de remplir le tampon avant que cela ne soit fait automatiquement. Dans le premier cas, il existe la fonction standard fflush qui permet de vider le tampon associé à un flux. Dans le second malheureusement, il n'existe pas de fonction toute faite, il est donc nécessaire de lire manuellement tous les caractères restant dans le tampon afin de sollicité une nouvelle lecture.
Dans le cas d'un flux pleinement mémorisé, cette opération peut-être réalisée à l'aide de cette boucle :
int c;
while ((c = getc(fp)) != EOF)
;
Pour un flux mémorisé par ligne, il faudra en plus vérifié la présence d'un caractère de fin de ligne :
int c;
while ((c = getc(fp)) != '\n' && c != EOF)
;
Puisqu'il n'y a pas eu d'autre retour, je me permet de poster mon entrée concernant la récupération d'un caractère sans appuyez sur Enter. Aussi, je propose l'entrée suivante :
[1][9] Comment faire pour cacher ce que l'utilisateur entre au clavier ?
La solution dépend de votre système d'exploitation :
- sous Windows, il est possible d'utiliser la fonction getch (déclarée dans l'en-tête conio.h) pour récupérer un caractère sans que ce dernier ne soit affiché;
- sous Unixoïde (GNU/Linux, BSD, Mac OS X, Solaris, ...), il est nécessaire de modifier les attributs du terminal (à l'aide des fonctions de l'en-tête termios.h), afin de supprimer l'echo (c'est à dire le fait que les caractères entrés soit affiché).
Voici une fonction identique à fgets mais qui n'affiche pas ce que l'utilisateur entre au clavier :
#ifdef __unix
# define _XOPEN_SOURCE 600
# include <termios.h>
# include <unistd.h>
#else
# include <conio.h>
#endif
#include <stdio.h>
char *
hide_fgets(char *buffer, int size, FILE *fp)
{
#ifdef __unix
struct termios term, tmp;
int fd = fileno(fp);
if (tcgetattr(fd, &term) < 0)
return NULL;
tmp = term;
tmp.c_lflag &= ~ECHO;
if (tcsetattr(fd, TCSAFLUSH, &tmp) < 0)
return NULL;
char *ret = fgets(buffer, size, fp);
tcsetattr(fd, TCSAFLUSH, &term);
return ret;
#else
int c, i;
size--;
for (i = 0; (c = getch()) != EOF && size-- != 0; ++i)
if ((buffer[i] = c) == '\n')
break;
buffer[i] = '\0';
return (ferror()) ? NULL : buffer;
#endif
}
int
main(void)
{
char buffer[BUFSIZ];
if (hide_fgets(buffer, sizeof buffer, stdin) != NULL)
fputs(buffer, stdout);
return 0;
}
Puisqu'il n'y a pas eu d'autre retour, je me permet de poster mon entrée concernant la récupération d'un caractère sans appuyez sur Enter. Aussi, je propose l'entrée suivante :
[1][9] Comment faire pour cacher ce que l'utilisateur entre au clavier ?
La solution dépend de votre système d'exploitation :
- sous Windows, il est possible d'utiliser la fonction getch (déclarée dans l'en-tête conio.h) pour récupérer un caractère sans que ce dernier ne soit affiché;
- sous Unixoïde (GNU/Linux, BSD, Mac OS X, Solaris, ...), il est nécessaire de modifier les attributs du terminal (à l'aide des fonctions de l'en-tête termios.h), afin de supprimer l'echo (c'est à dire le fait que les caractères entrés soit afficher).
Voici une fonction identique à fgets mais qui n'affiche pas ce que l'utilisateur entre au clavier :
#ifdef __unix
# define _XOPEN_SOURCE 600
# include <termios.h>
# include <unistd.h>
#else
# include <conio.h>
#endif
#include <stdio.h>
char *
hide_fgets(char *buffer, int size, FILE *fp)
{
#ifdef __unix
struct termios term, tmp;
int fd = fileno(fp);
if (tcgetattr(fd, &term) < 0)
return NULL;
tmp = term;
tmp.c_lflag &= ~ECHO;
if (tcsetattr(fd, TCSAFLUSH, &tmp) < 0)
return NULL;
char *ret = fgets(buffer, size, fp);
tcsetattr(fd, TCSAFLUSH, &term);
return ret;
#else
int c, i;
size--;
for (i = 0; (c = getch()) != EOF && size-- != 0; ++i)
if ((buffer[i] = c) == '\n')
break;
buffer[i] = '\0';
return (ferror()) ? NULL : buffer;
#endif
}
int
main(void)
{
char buffer[BUFSIZ];
if (hide_fgets(buffer, sizeof buffer, stdin) != NULL)
fputs(buffer, stdout);
return 0;
}
Je ne dirait pas que c'est nul mais inutile pour la majorité du site du zéro, car principalement quand on voit la question: " comment on mets les étoile, pour entrer le texte!!!! ", souvent les zéro sont rendus au pendu et je ne suis pas sur que s'il voit ton code il y comprenne grand chose, dû fait d'un niveau quand même soutenu (tout le monde ne connais pas termino.h par coeur ^^).
Je vois ce que tu veux dire, la solution est effectivement assez compliquée
J'avoue cependant que le but n'est pas ici d'expliquer la solution, mais simplement d'en proposer une utilisable sur la plupart des systèmes.
Attention Taurre ton code n'est pas valable sous windows, tu as oublier le paramètre fp dans la macro ferror(). De plus le caractère à tester pour la fin de ligne est '\r'.
En dehors de ces petites erreurs d’inattention (dû à un probable manque de test puisque j’imagine que tu n'as pas windows) il y a une différence plus subtile. Dans le code windows on stocke les éventuels caractère backslash, alors ça ne se voit pas à l'affichage mais le \b ainsi que le caractère effacé sont bel et bien présent dans la chaine. Pas terrible pour un mot de passe par exemple.
En considérant que la fonction n'a d'intérêt que pour une lecture sur stdin je rend la fonction un peut moins général comme ceci :
#ifdef __unix
# define _XOPEN_SOURCE 600
# include <termios.h>
# include <unistd.h>
#else
# include <conio.h>
#endif
#include <stdio.h>
#include <stdbool.h>
char *hide_gets (char *buffer, int size)
{
#ifdef __unix
struct termios term, tmp;
int fd = fileno (stdin);
if (tcgetattr (fd, &term) < 0)
return NULL;
tmp = term;
tmp.c_lflag &= ~ECHO;
if (tcsetattr (fd, TCSAFLUSH, &tmp) < 0)
return NULL;
char *ret = fgets (buffer, size, stdin);
tcsetattr (fd, TCSAFLUSH, &term);
return ret;
#else
int i = 0;
bool entry = false;
while (entry == false)
{
buffer[i] = _getch ();
switch (buffer[i])
{
case '\r': // if carriage return
entry = true;
break;
case '\b': // if backslash
if (i > 0)
{ // underflow check
fputs ("\b \b", stdout);
i--;
}
break;
default:
if (i < size - 1)
++i; // overflow check
break;
}
}
buffer[i] = '\0';
return (ferror(stdin)) ? NULL : buffer;
#endif
}
int main (void)
{
char buffer[BUFSIZ];
if (hide_gets (buffer, sizeof buffer) != NULL)
fputs (buffer, stdout);
return 0;
}
Et j'espère que ça à le même comportement sous UNIX mais là c'est à mon tour d'être coincé pour les tests.
Sous windows les fins de ligne sont en "\r\n", le '\r' tout seul c'était traditionnellement les fin de ligne sous Mac OS. Mais peut être que le '\n' n'est pas mis dans le buffer sous windows ?
Erf, je ne sais pas bien. Mais pour avoir testé, je peux assurer que le '\n' ne vient jamais dans la console cmd sous windows XP et windows 7 (donc probablement sur les autres aussi).
Attention Taurre ton code n'est pas valable sous windows, tu as oublier le paramètre fp dans la macro ferror(). De plus le caractère à tester pour la fin de ligne est '\r'.
En effet, merci de me l'avoir fait remarqué
Citation : simbilou
En dehors de ces petites erreurs d’inattention (dû à un probable manque de test puisque j’imagine que tu n'as pas windows)
Je n'ai effectivement pas Windows sur mon pc, seulement Debian squeeze. Heureusement (ou malheureusement c'est selon), je l'ai sur un autre pc. J'ai donc fait le test et getch ne retourne en effet le caractère '\r' et non '\n' comme getchar... bizarre cette histoire
Citation : simbilou
il y a une différence plus subtile. Dans le code windows on stocke les éventuels caractère backslash, alors ça ne se voit pas à l'affichage mais le \b ainsi que le caractère effacé sont bel et bien présent dans la chaine. Pas terrible pour un mot de passe par exemple.
Aah... Bien vu ! C'est un problème auquel je n'avais pas pensé
Voici un code corrigé suivant ces remarques (du coup il est encore plus complexe, je crois que je vais laisser tomber cette entrée ) :
#ifdef __unix
# define _XOPEN_SOURCE 600
# include <termios.h>
# include <unistd.h>
#else
# include <conio.h>
#endif
#include <stdio.h>
char *
hide_fgets(char *buffer, int size, FILE *fp)
{
#ifdef __unix
struct termios term, tmp;
int fd = fileno(fp);
if (tcgetattr(fd, &term) < 0)
return NULL;
tmp = term;
tmp.c_lflag &= ~ECHO;
if (tcsetattr(fd, TCSAFLUSH, &tmp) < 0)
return NULL;
char *ret = fgets(buffer, size, fp);
tcsetattr(fd, TCSAFLUSH, &term);
return ret;
#else
int c, i = 0;
--size;
while ((c = _getch()) != EOF && --size != 0)
if ((buffer[i] = c) == '\r') {
buffer[i++] = '\n';
break;
} else if (c == '\b' && i) {
buffer[--i] = '\0';
++size;
} else
++i;
buffer[i] = '\0';
return (ferror(fp)) ? NULL : buffer;
#endif
}
int
main(void)
{
char buffer[BUFSIZ];
if (hide_fgets(buffer, sizeof buffer, stdin) != NULL)
fputs(buffer, stdout);
return 0;
}
EDIT : simplification du code du côté des Unixoïdes.
Je me permets de remonter le sujet afin de proposer une autre version de l'entrée concernant les tampons et deux nouvelles sur la différence entre C et C++ et le choix d'un premier langage :
[1][9] Que sont les tampons ? Comment les manipuler ?
En informatique, la lecture et l'écriture de données depuis ou sur un disque dur prends un temps assez important. Afin d'éviter cette problématique, il existe en C un tampon qui est associé à chaque flux (chaque structure FILE si vous préférez). Ce tampon n'est rien d'autre qu'une zone mémoire d'une certaine taille dans laquelle vont être stockés les données devant être lues ou écrites depuis ou sur le disque dur. Ainsi, au lieu de sollicité le disque dur pour lire ou écrire un caractère à la fois (ce qui est très lent), il ne sera appelé que lorsque le tampon sera vide (pour une lecture) ou plein (pour une écriture).
Un flux peut disposer de trois types de tampons :
aucun : le flux ne dispose pas d'un tampon;
par bloc : le tampon est remplit ou vidé lorsqu'il est vide ou plein;
par ligne : identique à un tampon par bloc mis à part qu'il est également remplit ou vidé lorsqu'un caractère de fin de ligne ('\n') est rencontré;
Il est possible de modifier le type et la taille du tampon associé à un flux à l'aide de la fonction standard setvbuf (déclarée dans l'en-tête stdio.h). Voici son prototype :
int setvbuf(FILE *stream, char *buf, int mode, size_t size);
Où « stream » est le flux concerné, « buf » le nouveau tampon, « size » la taille de celui-ci et « mode » le type de tampon. Ce dernier est spécifié par une des constantes suivantes :
_IONBF : aucun tampon;
_IOFBF : tampon par bloc;
_IOLBF : tempon par ligne.
Si « buf » est nul, le tampon sera alloué par la fonction et sera d'une taille déterminée par le système (le paramètre « size » n'est pas forcément pris en compte).
N'essayez pas d'accéder au contenu du tampon ! Ce dernier est indéterminé et vous pourriez dès lors rencontré des erreurs.
Veillez à ce que le tampon que vous passez en argument de setvbuf ait une durée de vie au moins aussi longue que le flux auquel il est associé !
Il arrive parfois que l'on ait besoin de remplir ou de vider le tampon avant que cela ne soit fait automatiquement. Par exemple, dans le cas d'une écriture, parce que l'on souhaite être certains que les données présentes dans le tampon seront écrites ou, dans le cas d'une lecture, parce que les données présentes dans ce dernier ne nous intéresse plus.
Dans le cas d'une écriture, il est possible d'utiliser la fonction fflush qui permet de vider le tampon associé à un flux. Dans le cas d'une lecture, il n'existe malheureusement pas de fonction toute faite, il est donc nécessaire de lire les caractères restants afin de déclencher une nouvelle lecture. Cette opération n'a de sens que dans le cas des tampons par ligne et peut être réalisée à l'aide de cette boucle :
int c;
while ((c = getc(fp)) != '\n' && c != EOF)
;
Où « fp » est le flux concerné.
[8][15] Quel est le meilleur langage entre le C et le C++ ?
La bonne réponse est : aucun des deux
Les deux langages ont une approche différentes quant à la manière de résoudre les problèmes et de structurer les programmes, mais sont capable des même choses. À vous, donc, de vous forger une opinion et de choisir le langage qui vous convient le mieux
[8][15] Je suis perdu face à la multitude de langages existants, lequel choisir ?
Il n'y a malheureusement pas de réponse générale et transcendante à cette question.
Cela dépend de ce que vous souhaitez réaliser, de vos attentes ainsi que de vos goûts. Le mieux est sans doute de commencer avec un langage dont le nom ou la syntaxe vous parle et de changer si finalement il ne vous plaît pas.
Si tu parles des tampons, je pense qu'on pourrait peut-être merger toutes les entrées qui parlent de scanf, la saisie sécurisée, le buffer, etc. Histoire d'avoir UN truc vers lequel rediriger toutes les questions d'entrées.
Pour C vs C++, je pense qu'on pourrait gagner à rajouter des liens vers des topics intéressants ou des articles sur le Web. L'idéal serait d'avoir une réponse assez construite pour pouvoir fermer n'importe quel sujet en disant « CF la FAQ ». En l'état actuel, ça fait un peu court pour clore n'importe quel débat...
En ce qui concerne [8][15], « ce que vous souhaitez réalisé » --> « réaliser ». Pareillement, faire un petit paragraphe sur « prenez celui qui vous plaît, au pire vous pourrez changer plus tard » permettrait de fermer directement tous les débats sur le sujet.
Enfin, la section 8 commence à être bien remplie. Une idée pour la couper (au moins en deux) ?
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Si tu parles des tampons, je pense qu'on pourrait peut-être merger toutes les entrées qui parlent de scanf, la saisie sécurisée, le buffer, etc. Histoire d'avoir UN truc vers lequel rediriger toutes les questions d'entrées.
En fait, mon intention était effectivement de n'avoir plus que deux entrées à ce sujet : une expliquant ce que sont les tampons et une expliquant scanf en profondeur
Citation : GuilOooo
Pour C vs C++, je pense qu'on pourrait gagner à rajouter des liens vers des topics intéressants ou des articles sur le Web. L'idéal serait d'avoir une réponse assez construite pour pouvoir fermer n'importe quel sujet en disant « CF la FAQ ». En l'état actuel, ça fait un peu court pour clore n'importe quel débat...
Effectivement, c'est vrai que c'est un peu court, mais au final c'est ce qu'il ressort toujours de ce débat. M'enfin, concernant les sujets intéressants, il y a celui-ci.
Citation : GuilOooo
En ce qui concerne [8][15], « ce que vous souhaitez réalisé » --> « réaliser ».
Merci, c'est corrigé
Citation : GuilOooo
Enfin, la section 8 commence à être bien remplie. Une idée pour la couper (au moins en deux) ?
Le problème, c'est que les question de cette section sont assez diverses et donc difficiles à rassembler. Maintenant, certaines entrées pourraient, à mon avis, disparaître car leurs question est intégralement traitée par un tutoriel (je pense notamment aux fonctions de time.h et à l'allocation dynamique d'un tableau).
Maintenant, certaines entrées pourraient, à mon avis, disparaître car leurs question est intégralement traitée par un tutoriel (je pense notamment aux fonctions de time.h et à l'allocation dynamique d'un tableau).
Oui, de même que scanf est traitée dans plusieurs tutos C, et même dans le cours officiel. Le gros problème est de donner de la visibilité à ces cours (et même aux FAQ)... Je suis preneur de n'importe quelle idée à ce sujet.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
On essaie de minimiser l'usage de messages semi-autos, car ils sont mal perçus par les membres (et pas toujours efficaces). Si on doit introduire 5 messages semi-auto par forum (faut penser qu'il n'y a pas que le C), ça risque de devenir relativement ingérable.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Si tu veux prévoir ce genre de choses, ce sera plutôt sur la v4 du site. Donc tu peux aller voir la beta-test et réfléchir à comment tu intégrerais ça, puis faire une suggestion. Elle ne sera peut-être pas implémentée dans l'heure (les devs n'ont effectivement pas que ça à faire), mais si elle reçoit du soutien, elle pourra finir par l'être.
D'un point de vue plus pratique, il faudrait se mettre d'accord pour bien faire référence à la FAQ aussi souvent que possible. Je l'ai relue récemment, et j'y ai trouvé des réponses dont j'avais totalement oublié qu'elles y étaient. On pourrait sûrement gagner à en enrichir certaines (tout ce qui concerne la configuration de Code::Blocks, undefined reference...) et à poster le lien partout.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
D'un point de vue plus pratique, il faudrait se mettre d'accord pour bien faire référence à la FAQ aussi souvent que possible. Je l'ai relue récemment, et j'y ai trouvé des réponses dont j'avais totalement oublié qu'elles y étaient. On pourrait sûrement gagner à en enrichir certaines (tout ce qui concerne la configuration de Code::Blocks, undefined reference...) et à poster le lien partout.
Je suis entièrement d'accord sur ce point, pas mal d'entrée de la FAQ C sont peu ou pas connues et gagnerait à être citée plus souvent. Malheureusement, il y en a aussi certaines qui sont mal formulées (« pourquoi scanf est mal ? ») et d'autre qui contiennent des informations erronées (« scanf est mal ») et il faudrait les revoir ou les corriger.
Aussi, je me demandais si la forme d'un sujet est la bonne ? Ne pourrait-on pas imaginer un mini-tuto à la place afin que plusieurs auteurs puissent la modifier ?
Quitte à faire un mini-tuto, autant en faire un sur un point précis (configuration de C::B, entrées-sorties avancées, etc.) Autrement, ce sera un « TEA », donc refusé à la validation. En outre, le sujet permet une indexation simple (un post par entrée avec sommaire dans le PO).
Si tu veux éditer une réponse, tu peux m'envoyer un MP. C'est un poil plus lent et lourd, mais a priori on ne touchera pas à la FAQ tous les jours.
Si on souhaite entreprendre de grands travaux dessus, on peut toujours faire un dépôt git et mettre le zCode dessus.
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Je propose un brouillon pour l'entrée sur le C et le C++.
[8][15] Quel est le meilleur langage entre le C et le C++ ?
Réponse courte : aucun des deux. Réponse plus longue : les deux langages sont différents sur de nombreux points. Le C est un langage impératif inventé au début des années 1970 et qui était destiné à la programmation système ; le C++ a été inventé une dizaine d'années plus tard, et son but était d'ajouter la POO au C, au départ avec seulement les classes, puis avec de nombreux éléments (héritage, polymorphisme, surcharge d'opérateurs, templates, RAII, etc). Le temps a passé, et les deux langages se sont beaucoup différenciés, au point que le C++ ne ressemble plus vraiment au "C with class" qu'il était au départ.
Comme le montre ce petit passage historique, il existe de nombreuses différences entre les deux langages au niveau des éléments, mais il en existe d'autres. Le C++ permet une certaine abstraction (comme string à la place des char*, ou cout et cin) et certains techniques utiles (comme les templates ou les vector), mais il reste plus compliqué que le C et plus long à maitriser. Le C++ est d'autant plus dur à maitriser qu'il se base sur le C (et sur ses défauts) en plus de ceux qu'il ajoute. La façon de penser et de coder est aussi différente entre les deux langages : en C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts). Il est toutefois possible de faire un semblant de POO en C, et on peut programmer avec beaucoup de paradigmes différents en C++.
C'est le programmeur qui décide du langage à utiliser. S'il arrive mieux à découper le problème en sous-problèmes, il pourra choisir le C ; si au contraire il visualise mieux avec des objets, il prendra plus le C++ (je parle ici dans le cadre d'un projet dans lequel le langage est libre, sinon la question ne se pose pas). Tout dépend de comment il voir le problème et de son affinité avec chacun des deux langages.
En tant que programmeurs amateurs, vous êtes libres de choisir le langage que vous préférez. Le meilleur moyen de se faire un opinion, c'est d'essayer les deux langages et de choisir celui qui plait le plus. Chacun a ses avantages et ses inconvénients, et chacun sait être puissant quand on l'utilise bien. Lisez donc des tutoriels sur chacun des deux, faites votre choix et surtout, prenez du plaisir à programmer avec !
<gras>[8][15] Quel est le meilleur langage entre le C et le C++ ?</gras>
Réponse courte : aucun des deux. Réponse plus longue : les deux langages sont différents sur de nombreux points. Le C est un langage impératif inventé au début des années 1970 et qui était destiné à la programmation système ; le C++ a été inventé une dizaine d'années plus tard, et son but était d'ajouter la POO au C, au départ avec seulement les classes, puis avec de nombreux éléments (héritage, polymorphisme, surcharge d'opérateurs, templates, RAII, etc). Le temps a passé, et les deux langages se sont beaucoup différenciés, au point que le C++ ne ressemble plus vraiment au "C with class" qu'il était au départ.
Comme le montre ce petit passage historique, il existe de nombreuses différences entre les deux langages au niveau des éléments, mais il en existe d'autres. Le C++ permet une certaine abstraction (comme <minicode type="cpp">string</minicode> à la place des <minicode type="c">char*</minicode>, ou <minicode type="cpp">cout</minicode> et <minicode type="cpp">cin</minicode>) et certains techniques utiles (comme les <minicode type="cpp">templates</minicode> ou les <minicode type="cpp">vector</minicode>), mais il reste plus compliqué que le C et plus long à maitriser. Le C++ est d'autant plus dur à maitriser qu'il se base sur le C (et sur ses défauts) en plus de ceux qu'il ajoute. La façon de penser et de coder est aussi différente entre les deux langages : en C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts). <taille valeur="tpetit">Il est toutefois possible de faire un semblant de POO en C, et on peut programmer avec beaucoup de paradigmes différents en C++</taille>.
C'est le programmeur qui décide du langage à utiliser. S'il arrive mieux à découper le problème en sous-problèmes, il pourra choisir le C ; si au contraire il visualise mieux avec des objets, il prendra plus le C++ (je parle ici dans le cadre d'un projet dans lequel le langage est libre, sinon la question ne se pose pas). Tout dépend de comment il voir le problème et de son affinité avec chacun des deux langages.
En tant que programmeurs amateurs, vous êtes libres de choisir le langage que vous préférez. Le meilleur moyen de se faire un opinion, c'est d'essayer les deux langages et de choisir celui qui plait le plus. Chacun a ses avantages et ses inconvénients, et chacun sait être puissant quand on l'utilise bien. Lisez donc des tutoriels sur chacun des deux, faites votre choix et surtout, prenez du plaisir à programmer avec !
Quelques liens intéressants : <lien url="http://www.siteduzero.com/forum-83-307908-p1-pourquoi-ne-pas-aller-vers-le-c.html">discussion sur le SdZ</lien>.
La façon de penser et de coder est aussi différente entre les deux langages : en C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts). Il est toutefois possible de faire un semblant de POO en C ,et on peut programmer en impératif avec le C++.
C'est le programmeur qui décide du langage à utiliser. S'il arrive mieux à découper le problème en sous-problèmes, il pourra choisir le C ; si au contraire il visualise mieux avec des objets, il prendra plus le C++ (je parle ici dans le cadre d'un projet dans lequel le langage est libre, sinon la question ne se pose pas). Tout dépend de comment il voir le problème et de son affinité avec chacun des deux langages.
Pas objectif : on peut tout à fait naturellement coder en procédural avec le C++, ce qui n'est pas le cas de C pour l'OO.
il existe de nombreuses différences entre les deux langages au niveau des éléments, mais il en existe d'autres
Je ne comprends pas ce bout de phrase, notamment ce à quoi fait référence le terme « éléments ».
Tu as aussi écrit « certains techniques utiles » -> certaines. De même, « Tout dépend de comment il voir » -> il voit.
Je trouve l'avant dernier paragraphe peu clair, sans vraiment arriver à dire pourquoi. Il gagnerait à être fusionné avec le dernier paragraphe pour bien insister sur l'idée « essayez les deux et prenez celui qui vous plaît le mieux ».
J'ai déménagé sur Zeste de savoir — Ex-manager des modérateurs.
Les "éléments" dont je parle, c'est vrai que le terme n'est pas adapté, c'est pour parler des caractéristiques et du "contenu" du langage (en gros, ce qu'il y a dedans).
Voici une nouvelle version :
[8][15] Quel est le meilleur langage entre le C et le C++ ?
Réponse courte : aucun des deux. Réponse plus longue : les deux langages sont différents sur de nombreux points. Le C est un langage impératif inventé au début des années 1970 et qui était destiné à la programmation système ; le C++ a été inventé une dizaine d'années plus tard, et son but était d'ajouter la POO au C, au départ avec seulement les classes, puis avec de nombreux éléments (héritage, polymorphisme, surcharge d'opérateurs, templates, RAII, etc). Le temps a passé, et les deux langages se sont beaucoup différenciés, au point que le C++ ne ressemble plus vraiment au "C with class" qu'il était au départ.
Comme le montre ce petit passage historique, il existe de nombreuses différences entre les deux langages au niveau du contenu et des caractéristiques, mais il en existe d'autres. Le C++ permet une certaine abstraction (comme string à la place des char*, ou cout et cin) et certaines techniques utiles (comme les templates ou les vector), mais il reste plus compliqué que le C et plus long à maitriser. Le C++ est d'autant plus dur à maitriser qu'il se base sur le C (et sur ses défauts) en plus de ceux qu'il ajoute. La façon de penser et de coder est aussi différente entre les deux langages : en C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts). Il est toutefois possible de faire un semblant de POO en C, et on peut programmer avec beaucoup de paradigmes différents en C++.
Et les programmeurs expérimentés, comment font-ils eux pour choisir entre le C et le C++ pour un projet (je parle des programmeurs qui ont de l'expérience et pas forcément des programmeurs du monde professionnel où bien souvent on a pas le choix) ? C'est simple, en fonction de comment ils visualisent le problème. Si le programmeur arrive mieux à découper son problème en sous-problèmes traitables chacun par une fonction, il choisira plus le C ; si au contraire il arrive à représenter son projet à l'aide d'objets, il s'orientera plus vers le C++. Tout dépend de cette visualisation (et aussi de ses compétences dans chacun des deux langages). En tant que programmeurs amateurs, vous êtes libres de choisir le langage que vous préférez. Le meilleur moyen de découvrir lequel des deux langages conviendra le plus pour un certain projet, c'est de les essayer et de choisir celui qui plait le plus. Chacun a ses avantages et ses inconvénients, et chacun sait être puissant quand on l'utilise bien. Lisez donc des tutoriels sur chacun des deux, faites votre choix et surtout, prenez du plaisir à programmer avec !
<gras>[8][15] Quel est le meilleur langage entre le C et le C++ ?</gras>
Réponse courte : aucun des deux. Réponse plus longue : les deux langages sont différents sur de nombreux points. Le C est un langage impératif inventé au début des années 1970 et qui était destiné à la programmation système ; le C++ a été inventé une dizaine d'années plus tard, et son but était d'ajouter la POO au C, au départ avec seulement les classes, puis avec de nombreux éléments (héritage, polymorphisme, surcharge d'opérateurs, templates, RAII, etc). Le temps a passé, et les deux langages se sont beaucoup différenciés, au point que le C++ ne ressemble plus vraiment au "C with class" qu'il était au départ.
Comme le montre ce petit passage historique, il existe de nombreuses différences entre les deux langages au niveau du contenu et des caractéristiques, mais il en existe d'autres. Le C++ permet une certaine abstraction (comme <minicode type="cpp">string</minicode> à la place des <minicode type="c">char*</minicode>, ou <minicode type="cpp">cout</minicode> et <minicode type="cpp">cin</minicode>) et certaines techniques utiles (comme les <minicode type="cpp">templates</minicode> ou les <minicode type="cpp">vector</minicode>), mais il reste plus compliqué que le C et plus long à maitriser. Le C++ est d'autant plus dur à maitriser qu'il se base sur le C (et sur ses défauts) en plus de ceux qu'il ajoute. La façon de penser et de coder est aussi différente entre les deux langages : en C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts). <taille valeur="tpetit">Il est toutefois possible de faire un semblant de POO en C, et on peut programmer avec beaucoup de paradigmes différents en C++</taille>.
Et les programmeurs expérimentés, comment font-ils eux pour choisir entre le C et le C++ pour un projet (je parle des programmeurs qui ont de l'expérience et pas forcément des programmeurs du monde professionnel où bien souvent on a pas le choix) ? C'est simple, en fonction de comment ils visualisent le problème. Si le programmeur arrive mieux à découper son problème en sous-problèmes traitables chacun par une fonction, il choisira plus le C ; si au contraire il arrive à représenter son projet à l'aide d'objets, il s'orientera plus vers le C++. Tout dépend de cette visualisation (et aussi de ses compétences dans chacun des deux langages). En tant que programmeurs amateurs, vous êtes libres de choisir le langage que vous préférez. Le meilleur moyen de découvrir lequel des deux langages conviendra le plus pour un certain projet, c'est de les essayer et de choisir celui qui plait le plus. Chacun a ses avantages et ses inconvénients, et chacun sait être puissant quand on l'utilise bien. Lisez donc des tutoriels sur chacun des deux, faites votre choix et surtout, prenez du plaisir à programmer avec !
Quelques liens intéressants : <lien url="http://www.siteduzero.com/forum-83-307908-p1-pourquoi-ne-pas-aller-vers-le-c.html">discussion sur le SdZ</lien>.
Personnellement, je supprimerais le passage suivant :
Citation : informaticienzero
Le C++ permet une certaine abstraction (comme string à la place des char*, ou cout et cin) et certaines techniques utiles (comme les templates ou les vector), mais il reste plus compliqué que le C et plus long à maitriser. Le C++ est d'autant plus dur à maitriser qu'il se base sur le C (et sur ses défauts) en plus de ceux qu'il ajoute.
En effet, il ne faut pas perdre de vue que cette entrée a pour objectif de conseiller des débutants indécis, or les notions de template, vector ou autre joyeusetés leurs sont totalement inconnues, ce qui risque de les embrouiller plus que de les aider.
Je supprimerais également cette allusion :
Citation : informaticienzero
Il est toutefois possible de faire un semblant de POO en C, et on peut programmer avec beaucoup de paradigmes différents en C++.
étant donné que tu utilises la phrase « on pense plus en », cela ne signifie pas que c'est le seul paradigme utilisable.
Enfin, je supprimerais également le passage suivant (oui, je sais, j'élague ) :
Citation : informaticienzero
Et les programmeurs expérimentés, comment font-ils eux pour choisir entre le C et le C++ pour un projet (je parle des programmeurs qui ont de l'expérience et pas forcément des programmeurs du monde professionnel où bien souvent on a pas le choix) ? C'est simple, en fonction de comment ils visualisent le problème. Si le programmeur arrive mieux à découper son problème en sous-problèmes traitables chacun par une fonction, il choisira plus le C ; si au contraire il arrive à représenter son projet à l'aide d'objets, il s'orientera plus vers le C++. Tout dépend de cette visualisation (et aussi de ses compétences dans chacun des deux langages).
parce qu'il répète finalement ce qui a déjà été dit avant.
Bref, je propose cette version :
[8][15] Quel est le meilleur langage entre le C et le C++ ?
Réponse courte : aucun des deux. Réponse plus longue : les deux langages sont différents sur de nombreux points. Le C est un langage impératif inventé au début des années 1970 et qui était destiné à la programmation système ; le C++ a été inventé une dizaine d'années plus tard, et son but était d'ajouter la POO au C, au départ avec seulement les classes, puis avec de nombreux éléments (héritage, polymorphisme, surcharge d'opérateurs, templates, RAII, etc). Le temps a passé, et les deux langages se sont beaucoup différenciés, au point que le C++ ne ressemble plus vraiment au « C with class » qu'il était au départ.
Comme le montre ce petit passage historique, il existe de nombreuses différences entre les deux langages au niveau de leur contenu et de leurs caractéristiques, mais il y en a aussi dans la manière de penser et de concevoir un programme.
En C, on pense plus en terme de fonctions (un problème peut se découper en sous-problèmes, qui peuvent se découper en sous-problèmes, etc), en C++ on pense plus en terme de classes et de méthodes qui manipulent des attributs (on manipule des objets qui représentent des concepts).
En tant que programmeurs amateurs, vous êtes libres de choisir le langage que vous préférez. Le meilleur moyen de découvrir lequel des deux langages vous conviendra le mieux est de les essayer tous les deux. Chacun a ses avantages et ses inconvénients, renseignez-vous donc, faites votre choix et surtout, prenez du plaisir à programmer avec !
Objectif Zéro Bug - le test logiciel professionnel | L'électronique de zéro | Tableaux & pointeurs | Pointeurs sur fonctions | Lecture/écriture binaire
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.
🍊 - Étudiant - Codeur en C | Zeste de Savoir apprenez avec une communauté | Articles - ♡ Copying is an act of love.