Bonjour, l’idée d'un nouveau cours C++ plus moderne m'a beaucoup plu et j'en suis très impatient, est ce qu'une date a été fixé pour sa mise en ligne s'il vous plait?
Il va falloir que je trouve le temps de lire tout ca :S.
En parcourant le sommaire j’aperçois plusieurs concept qui m’intéresse afin d'évoluer un peu. Une fois fini ça seras super complet apparemment. (Même sans tome 2 ou 3 XD)
Le tuto de Mathieu Nebra donne tant de mauvais habitude que ça ? Si c'est le cas, j'ai du boulot
J'ai vu une option de téléchargement PDF c'est génial. Mais ça serais bien de pouvoir exporter l'ensemble du tuto plutôt que de le faire catégorie par catégorie :s.
Les meilleurs développeurs sont fainéants mais efficace !
J'ai vu une option de téléchargement PDF c'est génial. Mais ça serais bien de pouvoir exporter l'ensemble du tuto plutôt que de le faire catégorie par catégorie :s.
bonjour, je viens de commencer le cours de guillaume belz, et je voulais savoir si il y a une difference entre mettre std::cout<<"..."<<std::endl;
et mettre avant la fonction main using namespace std; pour ne pas remettre a chaque debut de phrase std:: . Ma question est peut etre sans interet car elle est d'un niveau debutant mais j'aimerais quand meme avoir une reponse. merci d'avance
oui, il y a une différence, et la question a un intérêt.
Utiliser "using namespace std" part d'un bon sentiment, vouloir se simplifier la vie.
mais il y a un moment où ça la complique : les noms qui se trouvent sans l'espace de nommage std (ceux qu'on précéderait de std::) peuvent très bien exister, avec d'autres significations, pourraient très bien exister dans d'autres espaces de nommage. Et là on va commencer à s'embrouiller. Conflits, ambiguités, tout ça.
Donc si on utilise de multiples bibliothèques simultanément, ce qui est souvent le lot des programmeurs professionnels, on doit s'abstenir d'utiliser "using namespace" pour éviter des emmerdements.
Maintenant il peut y avoir débat, comme sur pas mal de sujets, pour savoir si il est raisonnable d'imposer prématurément aux débutants - au titre des bonnes pratiques que les professionnels doivent respecter dans les gros programmes - une contrainte pour des problèmes qu'ils ne rencontreront en réalité pas de sitot dans leurs petits programmes, et qui va leur compliquer un peu la vie.
Parfois un peu beaucoup. Par exemple, un professionnel vérifiera qu'une lecture a réussi. Le débutant qui fait son exo du premier jour qui affiche la somme de deux nombres aura 20/20 avec
int main()
{
cout << "donnez deux nombres";
int a,b;
cint >> a >> b;
cout << "la sommme vaut " << a+b << endl;
}
(j'ai l'impression d'avoir oublié un truc ? :-)
je laisse le soin a d'authentiques professionnels de fournir la version "blindée". <troll>et à expliquer qu'on ne peut pas écrire un programme qui lit une donnée sans faire un test, donc faut avoir appris les tests, voire les boucles, avant de commencer à écrire son premier programme qui a besoin de lire un nombre.</troll>
@theo2000 Les explications sont données dans le chapitre "hello world", au début du cours.
@michelbillaud
michelbillaud a écrit:
Maintenant il peut y avoir débat, comme sur pas mal de sujets, pour savoir si il est raisonnable d'imposer prématurément aux débutants - au titre des bonnes pratiques que les professionnels doivent respecter dans les gros programmes - une contrainte pour des problèmes qu'ils ne rencontreront en réalité pas de sitot dans leurs petits programmes, et qui va leur compliquer un peu la vie.
Avec le recul, la raison principale n'est pas de "faire comme les pros", mais de pouvoir apprendre à distinguer ce qui vient de la STL ou ce qui vient du langage. (Au début de l'apprentissage, puisque les débutants ne connaissent que ca pour commencer. Et plus généralement, cela permet d'apprendre à se poser la question "d'où vient ce mot-clé" quand on lit un code).
Quand on dit a un débutant qui a appris avec "using namespace std" de ne plus utiliser cette syntaxe, il ne sait généralement pas devant quels mots-clés mettre "std::". Et ca, c'est un probleme. Cela montre qu'il n'a pas compris ce qu'il utilise. Et il n'y a pas de raison de ne pas corriger ce probleme des le debut du cours.
michelbillaud a écrit:
(j'ai l'impression d'avoir oublié un truc ? :-)
je laisse le soin a d'authentiques professionnels de fournir la version "blindée". <troll>et à expliquer qu'on ne peut pas écrire un programme qui lit une donnée sans faire un test, donc faut avoir appris les tests, voire les boucles, avant de commencer à écrire son premier programme qui a besoin de lire un nombre.</troll>
Il est évident qu'il ne faut pas forcément suivre à 100% les pratiques des pros dans un cours, surtout si cela complexifie le cours et rend la progression pédagogique inutilement dure.
Pour "using namespace std" vs "std::", la question est vite réglée : dans les 2 cas, on peut se contenter d'une explication de 10 secondes sur les espace de noms, puis c'est une simple question d'habitude.
Pour "std::cin", le probleme est plus intéressant. Effectivement, les recommandations de "bonnes" pratiques disent qu'il ne faut pas écrire un tel code. Et en fait, tu laisses entendre que l'on a que 2 choix : soit utiliser une syntaxe simple et ne pas respecter les "bonnes" pratiques ; soit utiliser les "bonnes" pratiques des pros et avoir un code plus complexe (et donc un cours moins accessible).
Je crois qu'au moins une 3eme approche est possible : de poser la question de savoir si "std::cin" est encore important de nos jours et sa place dans le cours.
Dans mon cours, je ne me suis pas pose la question des "bonnes" pratiques, je me suis simplement posé la question : quels sont les prérequis pour étudier une notion ? Cette notion sert de pré requis pour quelles autres notions ? Et j'ai pris aussi en compte l'importance (de mon point de vue) des notions (étudiées en premier les notions importantes).
Du coup, "std::cin" s'est naturellement retrouvé presqu'à la fin de la partie "programmation impérative", juste avant les chapitres sur la conceptions.
Ce qui est important, ce n'est pas de changer pour changer. C'est de reflechir a la pedagogie du cours, sans etre bloque par "comme on faisait avant". Ce que beaucoup de cours ont du mal a faire (et donc ajoutent les nouvelles fonctionnalites ou paradigmes en fin de cours, comme si c'etait des ajouts non coherents avec le reste du cours).
On peut detailler en se poser plusieurs questions :
michelbillaud a écrit:
écrire son premier programme qui a besoin de lire un nombre
Est-ce que savoir lire un nombre est une notion importante a connaitre ?
C'est une question etrange, tellement "std::cin" semble faire partie des notions de base. Mais si on pense aux programmes qui utilisent "std::cin", est-ce qu'il y en a beaucoup ? J'imagine que les Linuxis habitues aux lignes de commande en connaissent au moins 50.000, mais comme je bosse sur plusieurs plateforme, dont Mac, Android et iOS, je dirais que la grande majorite de mes programmes n'utilisent pas "std::cin".
Et si je ne fais pas expres de troller et que je prends en compte uniquement les programmes en mode console, la majorite utilisent les options de lignes de commnande, pas "std::cin". Dans cette logique, on devrait apprendre "argc/argv" avant "std::cin". (Dans mon cours, c'est vu au meme moment).
A quoi servent std::cout et std::cin ?
On presente souvent "std::cin: en complement de "std::cout". Il est vrai qu'ils sont assez lies.
Mais pour un debutant, a quoi sert "std::cout" ? A priori, on va utiliser "std::cout" pour voir le comportement de son programme a l'execution, voir si son code fait que l'on pense qu'il a ecrit. C'est indispensable pour un debutant de faire cela.
Par contre, "std::cin" n'est pas la seule facon de "mettre" des infos dans un code, pour le tester. On peut tout simplement mettre directement les entrees dans le code. Au lieu de lancer un programme, entrer la valeur et voir le comportement, on ecrit la valeur dans une variable, on lance le programme et on regarde le comportement.
(HS : D'ailleurs, c'est ce que je fais souvent quand je testes des codes de debutants sur coliru.com. Je remplace le "std::cin" par une initialisation de variable. Comme ca, pas besoin de m'embeter a taper l'entree a chaque fois).
Encore une fois, on presente "std::cin" en debut de cours, parce que "c'est comme ca qu'on a toujours fait". Mais en pratique, on n'interagit plus beaucoup avec les utilisateurs de cette facon. C'est une notion a apprendre, mais plus une notion fondamentale, qui doit etre vue au debut du cours.
Qu'est sont les problemes poses par std::cin ?
Bien sur, il y a le probleme des "bonnes" pratiques. On va balayer cet argument en disant que les "bonnes" pratiques ne doivent pas prendre le pas sur la pedagogie.
Il y a un point que tu cites et qui me semble completement fondamental : les tests.
Comment un debutant juge que son code est correct ? En premier, s'il compile. Souvent, ils laissent de cote les warnings. Deja un probleme. Et ensuite, quand le programme reussit a fonctionner, ils testent 2 ou 3 valeurs et si cela donne le resultat attendu, c'est bon. Ce qui est aussi un probleme.
Dans un cours IRL, c'est le prof qui va relire les codes et verifier que le code est valide pas uniquement pour les quelques valeurs testes. Dans un cours en ligne, on va generalement utiliser des tests automatiques pour tester les valeurs limites. (C'est ce que je compte faire).
Mais surtout, le point important (a mon sens) a enseigner aux debutants, c'est qu'un programme ne se teste pas avec 2 ou 3 valeurs. Il faut apprendre ce qu'est un code valide. Et je trouve que la facon dont "std::cin" est utilise actuellement dans beaucoup de cours n'aide pas le debutant a reflechir a ce probleme.
En conclusion, ce que je reproche a beaucoup de cours actuels de C++, c'est de ne pas avoir reussit a mettre a jour la pedagogie, en se detachant des idees preconcus. Ce qui donne au final une mauvaise pedagogie.
L'apprendre au début, c'est une approche suivie dans l'enseignement de la programmation depuis l'avènement des ordinateurs personnels, pour avoir des exemples interactifs et "donc" motivants. C'est fou comme ils sont plus facile à motiver pour écrire un jeu interactif plutôt qu'un truc qui lance une série de tests unitaires.
En fait, l'histoire du std, ça relève d'une autre catégorie de qualité que la syntaxe correcte ou l'exécution qui marche. C'est la lisibilité/maintenabilité/réutilisabilité du texte.
PS : quand je parlais de test, c'était pour la vérification que cin >> a >> b n'a pas échoué, pas les tests unitaires et autres, qui ont bien sur leur place.
PS2: on peut en effet remettre beaucoup de choses en question (et à leur place) si on se pose la question de pourquoi elles sont là. Je suis en train de bosser sur un cours de débutants (basé sur Processing) pour la rentrée où on verra la notion de fonction AVANT celle de variable et d'affectation:-) alors que ça venait traditionnellement après constantes, variables, affectation, si alors, boucle, tableaux, et fonctions à la fin. Déjà une fonction (même sans paramètre ni valeur retournée), c'est utile pour donner un nom à un bout de code quand on décompose le travail. Décomposer, c'est vraiment l'outil de base quand on programme, alors on le fait dès la première heure.
L'apprendre au début, c'est une approche suivie dans l'enseignement de la programmation depuis l'avènement des ordinateurs personnels, pour avoir des exemples interactifs et "donc" motivants. C'est fou comme ils sont plus facile à motiver pour écrire un jeu interactif plutôt qu'un truc qui lance une série de tests unitaires.
Meme le plus simple des jeux, par exemple un simple "deviner le nombre" nécessite de connaître les boucles et les tests. Donc quand on a aussi les connaissances pour tester les entrées de "std::cin".
Et écrire une jeu n'est pas la seule approche pour rendre des exos motivant. Parmis les exos intéressants que j'ai déjà vu (pas forcément qu'en C++), c'est des exos de hacking (écrire des boucles et tests simples pour decoder une phrase chiffrées), d'IA (idem, de simples boucles et tests pour diriger une drone dans un interface 3D). Et on peut trouver pleins de domaines d'application, qui vont intéresser les débutants, sans avoir besoin d'utiliser "std::cin".
L'argument "motiver les élèves" n'est donc pas suffisant pour moi face aux 2 arguments de la qualité du code et l'apprentissage que l'on ne teste pas un programme avec 2-3 valeurs.
Et l'argument "depuis l'avènement des ordinateurs" est justement ce que je critiquais et qui empêche de repenser la pédagogie des cours.
michelbillaud a écrit:
PS2: on peut en effet remettre beaucoup de choses en question (et à leur place) si on se pose la question de pourquoi elles sont là. Je suis en train de bosser sur un cours de débutants (basé sur Processing) pour la rentrée où on verra la notion de fonction AVANT celle de variable et d'affectation:-) alors que ça venait traditionnellement après constantes, variables, affectation, si alors, boucle, tableaux, et fonctions à la fin. Déjà une fonction (même sans paramètre ni valeur retournée), c'est utile pour donner un nom à un bout de code quand on décompose le travail. Décomposer, c'est vraiment l'outil de base quand on programme, alors on le fait dès la première heure.
L'idee est interessante, je n'y avais pas pense. Je ne sais pas ce que ca pourrait donner, il faut que je pense a ca.
Comme il s'en tient à la bibliothèque C, il est quand même obligé de causer de variables dès le début, mais voila l'idée. Je vous la fais en C++ à ma sauce :
1) faire utiliser une fonction prédéfinie
int main()
{
int n;
std::cin >> n;
int r = abs(n);
std::cout << "valeur absolue = " << r << std::endl;
}
2) paf, la même mais avec une fonction à écrire
int main()
{
int n;
std::cin >> n;
int r = square(n);
std::cout << "carre = " << r << std::endl;
}
int square(int n)
{
return n * n;
}
Ce qui coince un peu dans son approche c'est qu'il utilise C pour faire des calculs, donc il est obligé de mettre assez tot le petit doigt dans variable, constante, expression, operateurs, et patin coufin.
Quand c'est avec un langage "jouet" pour piloter une tortue ou faire des dessins (Logo, processing, ...), on a suffisamment assez de "blocs de base" pour avoir l'idée de construire des suites assez complexes d'actions, avec une décomposition assez naturelle.
Par exemple, avec Arduino, au lieu de montrer comment écrire des loop() d'un mètre de long, on pourrait commencer par leur faire des séquences
EDIT: ce que j'en dis, c'est l'approche pour des débutants complets. Qui sont déjà embrouillés par des confusions compiler/exécuter, points virgules et accolades, ... Si on fait l'approche traditionnelle on y ajoute d'un coup la notion de bloc, la portée des variables, les syntaxes if/while/do/for etc. sans compter les notions d'algorithmique (utilisations d'une variable comme index, comme compteur, comme cumul,...). Ca fait beaucoup trop, surcharge cognitive et l'apprenant se bloque et/ou pète les plombs. Donc au lieu de faire ça, on joue à décomposer, à construire un programme par étapes, en donnant aux fonctions des noms qui correspondent à des responsabilités bien définies, en attendant que la panique se calme un peu. On introduira le reste après. De toutes façons, approche en spirale, on montre d'abord une utilisation concrète immédiate d'une notion simplifiée, on y revient plus tard pour étendre... On verra ce que ça donne quand on l'aura testé en septembre.
salut a tous, je me posais une question, un bit est un chiffre binaire, par exemple le nombre 1 est egal a 0001 en binaire donc 4 bits(je sais pas si je suis deja en train de dire une connerie ou pas ),8 bit = 1 octet donc j'ai compris que les bits pouvait être utilisé comme taille mais je ne comprend pas quand on dit que tel console est en 64 bits ou tel ordinateur en 32 bits. Ça veut dire quoi car évidemment ce n'est pas une taille (je pense pas qu'un ordinateur à 4 octet existe) donc j'en ai déduit que c’était une vitesse et qu'on raccourcissait au lieu de 32 bit/sec (pour l'ordinateur),on mettait 32 bits mais je ne suis pas sûr de ma theorie.
salut a tous, je me posais une question, un bit est un chiffre binaire, par exemple le nombre 1 est egal a 0001 en binaire donc 4 bits(je sais pas si je suis deja en train de dire une connerie ou pas ),8 bit = 1 octet donc j'ai compris que les bits pouvait être utilisé comme taille mais je ne comprend pas quand on dit que tel console est en 64 bits ou tel ordinateur en 32 bits. Ça veut dire quoi car évidemment ce n'est pas une taille (je pense pas qu'un ordinateur à 4 octet existe) donc j'en ai déduit que c’était une vitesse et qu'on raccourcissait au lieu de 32 bit/sec (pour l'ordinateur),on mettait 32 bits mais je ne suis pas sûr de ma theorie.
Quelqu'un pourrait m'expliquer ?
- Edité par theo2000 23 août 2017 à 20:25:04
Non, un bit, c'est un interrupteur; quelque chose qui laisse passer le courant ou non. En gros, les seules valeurs possibles pour un bit sont donc 0 et 1!
un byte est un groupement de 8 bits (du moins, sans la plupart des cas), et c'est aussi le plus petit groupement "insécable" de bits que l'on rencontre. C'est grâce aux (8) bits qui le composent que l'on arrive à représenter des valeurs autres que 0 ou 1 (8 bits permettent de représenter un total de 256 combinaisons différentes, soit des valeurs allant de 0 à 255 inclus ou allant de -128 à + 127, selon le sens que l'on donne à l'un des bits en question)
Comme 256 valeurs différentes, ca fait pas vraiment lourd (juste assez pour représenter la plupart des caractères d'utilisation courante en anglais), d'autres types permettent de représenter des valeurs numériques grâce au fait qu'ils sont composés de plusiseurs bytes (et donc d'un nombre de bit qui est systématiquement un multiple de 8 :D).
Certains de ces types (short, int, long et long long) sont destinés à la représentation de valeurs entières (128 512, par exemple) et d'autres (float, double et long double) sont destinés à la représentation de valeurs réelles (3.1415926, par exemple)
En toutre, le nombre de bits d'une architecture correspond au nombre de bits qui est utilisé "naturellement" par le matériel mis à disposition de l'architecture. Cela n'a rien à voir avec une quelconque vitesse (autrement, nous parlerions de bits / seconde).
Cela correspond réellement au fait que le système "donnera toute la puissance dont il est capable" lorsqu'il manipulera le nombre de bits indiqué, et que, d'une certaine manière, s'il se met à manipuler un nombre de bits différent (pour différentes raisons), il ne profitera pas au mieux des possibilités dont il dispose
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Okay, donc si je comprend bien un bit est un interrupteur qui fait une action ou non comme un booleen, mais je ne comprends pas le rapport entre ca et la puissance que peut "degager "un ordinateur
Okay, donc si je comprend bien un bit est un interrupteur qui fait une action ou non comme un booleen, mais je ne comprends pas le rapport entre ca et la puissance que peut "degager "un ordinateur
- Edité par theo2000 il y a 22 minutes
Comme "puissance dégagée par un ordinateur" ça ne veut pas dire grand chose (à part la puissance thermique), c'est en effet difficile de faire un lien.
Faut voir aussi que le terme architecture N-bits n'est pas clairement défini non plus. En géneral, ça veut dire que les chemins de données ont N bits, et que l'ALU peut traiter des données de cette taille d'un coup.
Mais concrètement, qu'est-ce qu'un bit ? moi, j'ai cru quand j'ai appris la lecon de gbdivers que l'ordinateur fonctionnait par language binaire donc avec des 0 et 1 et que 8 bits = 1 octet mais alors là malgre les explications qu'on m'a donné,je ne comprend vraiment pas le rapport entre du binaire et la puissance d'un appareil en bits !
Ça tombe bien car il n'y a aucun lien entre les deux.
Dire qu'un processeur est 32 bits, ça veut juste dire que c'est la taille du mot mémoire standard (qui sert notamment à stocker les adresses mémoire), comme ça peut être 64 ou 16 ou même huit.
Après, on peut très bien faire faire des opérations sur des nombre codé avec 64 bits à un processeur 32 bits, c'est juste plus long car il ne peut pas le faire en une seule instruction comme le ferait un processeur 64 bits.
d'accord merci epso, j'etais un peu désappointé avec ces histoires de puissance d'un appareil et derniere petite question, je suis le cours de gbdivers sur le C++ (qui est tres bien ecrit d'ailleurs) mais j'ai lu que son cours apprenait seulement l'ecriture C++ pour "console", je n'ai aucun souci avec ca mais ca m'a un peu demotive, car je suis venu pour pouvoir apprendre a faire des projets(plutot des jeux videos mais pas seulement),le probleme c'est que je ne sais pas du tout quel projet peut-on faire a la fin de ce cours comme les jeux videos ne marchent evidemment pas sur "console".
Après avir appris le C++, tu pourras te tourner vers l’apprentissage d’une bibliothèque graphique C++ (par exemple SFML en 2D). Mais si tu veux faire un jeu tourne toi plutôt vers un moteur de jeu type Unity.
Non merci,je prefererais apprendre vraiment et developper mon jeu entierement dont le moteur de jeu plutot que travailler avec un moteur pre-codé, mais avec comme seule connaisance : le C++ en console, que peut-on faire ? Quels projets peut-on construire ?
Il n'apprend pas le C++ pour console, il apprend le C++, qui est un langage de programmation, avec un certain nombre de bibliothèques standard.
Les bibliothèques standard ne font bien sur pas tout, et si tu veux développer des applications graphiques, tu utilises C++ pour écrire du code qui fait des appels à des bibliothèques graphiques.
Mais pour ça, il faut d'abord apprendre une partie non négligeable de C++. Et après ça, les principes de la bibliothèque que tu as choisi. C'est du boulot.
Architecte logiciel - Software craftsmanship convaincu.
Posez vos questions ou discutez informatique, sur le Discord NaN | Tuto : Preuve de programmes C
Discord NaN. Mon site.
Discord NaN. Mon site.
Architecte logiciel - Software craftsmanship convaincu.
Discord NaN. Mon site.
Discord NaN. Mon site.