Bonjour à tous !

Vous l'avez peut-être appris via les news, le cours de C++ est en cours de réécriture. C'est un projet assez ancien qu'avait M@teo21 mais, devant l'ampleur de la tâche, il a décidé de prendre un acolyte pour terminer le travail. Comme j'étais l'auteur d'un tuto qui se voulait la suite de l'ancien cours, il m'a demandé si je souhaitais participer à son grand projet.

Lire le cours

Pour l'instant, seule la première partie (11 chapitre) du cours a été modifiée.



Les chapitres suivants sont en cours de rédaction et devraient être publiés récemment.

Nous aider

Nous cherchons à récolter un maximum d'avis sur le cours pour en améliorer le plus possible la qualité. Et c'est là que vous pouvez nous aider.
Si vous détectez de petites erreurs, je vous invite à utiliser le système d'alertes du tutoriel. Il sera plus facile pour nous de réparer les inévitables petites coquilles.
Si par contre vous avez des commentaires plus conséquent sur le fond du cours, sur sa pédagogie ou si vous pensez que certains éléments manquent n'hésitez pas à le faire savoir dans ce sujet du forum. Nous pourrons alors discuter de ces éléments et vous présenter notre point de vue si nécessaire.

N'hésitez vraiment pas à critiquer, même durement, c'est le seul moyen d'arriver à un contenu de qualité.

Quelques informations sur la suite

Le but principal de la réécriture du cours était de le rendre indépendant du cours de C. La partie I que nous vous présentons maintenant est justement là pour ça. Elle présente les bases du langage sans s'encombrer des complications du C.
Un des autres objectifs principaux était aussi d'enseigner dès le départ les éléments essentiels du langage comme les string, vector ou encore les références.

La partie II sera consacrée à la POO et sera également moins dépendante du C. Par exemple, le TP va disparaître au profit d'un exercice plus adapté ne nécessitant pas une connaissance avancée des char*.
C'est aussi dans cette partie que certains éléments de mon cours avancé vont apparaître. Le polymorphisme par exemple y fera son apparition.

La partie III sera toujours consacrée à Qt. Comme indiqué dans la news, les chapitres seront modifiés pour prendre en compte la nouvelle version de la bibliothèque.

La partie IV sera dédié à une présentation de la bibliothèque standard du C++. On devrait y trouver notamment une présentation des concepts fondamentaux que sont les itérateurs, les foncteurs et comment utiliser les algorithmes fournis.

Finalement, la partie V présentera des notions plus avancées comme les templates et les exceptions.

Bref, il y a encore du travail.

Mais vous verrez, le C++ est vraiment cool !

Bien joué Meteo et Nanoc Déjà, à un moment donné je me suis dis qu'il fallait fusionner le cours de Nanoc avec l'officiel, mais alors créer toute une nouvelle partie pour les bases, vraiment chapeau !

Quant à moi, je viens tout juste de terminer la partie 1 désormais 2, et de télécharger Qt. Ceci dit, je n'étais pas assez familiarisé avec les références, donc cette mise à jour va être une bonne mise au point pour moi !

Cependant j'aurais une demande, et j'espère bien qu'elle sera prise en compte: Pouvez vous, Mateo et Nanoc, introduire un autre module que GUI de Qt, tels que le module réseau ou OpenGl (je cite ces deux là car il attirent le plus de programmeur: en effet tous programmeur veut bien assimiler la 3D, mais avec la maitrise du réseaux, et arriver à créer un jeu en ligne, ça sera fastoche).

Merci, et encore bravo

J'ai une suggestion : peut être pourriez vous évoquer un chapitre ou deux dédié(s) à boost.

En plus de rendre le tutoriel C++ indépendant du tutoriel C, je propose de retirer la partie consacrée au framework Qt. Étant donné que cette partie occupe déjà beaucoup d'espace, le volume et le prix du livre du zéro prévu par la suite ne suivront pas si d'autres notions interviennent (templates, exceptions, etc...). J'estime que le tutoriel devrait exclusivement se porter autour du langage C++, ses concepts, et ses bibliothèques natifs.

Par la suite, il est possible d'envisager de réaliser un autre tutoriel complètement axé autour de ce framework. Sachez aussi que l'aspect pédagogique ne se limite pas toujours à avoir des choses concrètes telles que des interfaces graphiques (cf le tutoriel Python).

Moi j aurais pensé a deux cours complètement différent , comme ceux qui veule apprendre le c et ensuite le c++ ( comme avant ) ou ceux qui veulent apprendre le c++ directement , et apprendre le c++ a la suite du cours de c serait plus facile que connaisance déja aquisse ...

Cette une très bonne première partie, vivement la deuxième.

Pour les trois premières réponses : Il est, je crois, plus attendu des commentaires sur la partie déjà réalisée que des suggestions de plan. D'ailleurs toutes celles que vous proposez ont, il me semble, déjà été débattues et refusées.

Dans l'ensemble le cours est bien tourné mais passe à mon avis trop rapidement sur certaines notions.
Par exemples,
les types de variables : au moins nommer les quelques autres les plus connus même si ils sont moins utilisés : float, long long...)
les vectors : il est sûrement prévu d'en reparler mais peut-être parler de at() dés le début ?
le TP : peut-être exiger un peu plus du zéro. Un zéro trop avide de découvrir la suite réalisera le TP mais rarement les améliorations. Le TP en lui même étant pas très long, pourquoi ne pas demander quelques autres "fonctionnalité" dès le début ?

Bon travail pour la suite !

Ce serait mieux de faire pratiquer sur la SFML et faire un autre big tuto pour Qt.

Citation

D'ailleurs toutes celles que vous proposez ont, il me semble, déjà été débattues et refusées.

Tu nous donne un lien ?

Citation

Ce serait mieux de faire pratiquer sur la SFML et faire un autre big tuto pour Qt.

Selon moi c'est une bonne idée.

Citation : Hellish

Cependant j'aurais une demande, et j'espère bien qu'elle sera prise en compte: Pouvez vous, Mateo et Nanoc, introduire un autre module que GUI de Qt, tels que le module réseau ou OpenGl (je cite ces deux là car il attirent le plus de programmeur: en effet tous programmeur veut bien assimiler la 3D, mais avec la maitrise du réseaux, et arriver à créer un jeu en ligne, ça sera fastoche).

Il n'est pas prévu de présenter d'autres bibliothèques. Il y a énormément de bibliothèques différentes et il ne sera jamais possible de les présenter toutes. Les raisons qui ont poussé à utiliser Qt plutôt qu'une autre bibliothèque sont présentées dans le premier chapitre de la partie III.

Citation : captaingigicoin

J'ai une suggestion : peut être pourriez vous évoquer un chapitre ou deux dédié(s) à boost.

Boost est très important dans le monde du C++. Cependant, ce sont des outils avancés. Il y a très peu de choses de boost qui auraient leur place dans un cours d'initiation au langage. Par contre, il y aura peut-être un mot à la fin pour expliquer ce que c'est.

Citation : R@hl43

les types de variables : au moins nommer les quelques autres les plus connus même si ils sont moins utilisés : float, long long...)

C'est vrai, ces types existent. Mais ils n'ont que très peu d'intérêt lorsqu'on débute. Si tu en es à devoir gagner de la place en mémoire en utilisant des float à la place des double, c'est que tu n'est plus un débutant. De même pour les short ou les long long (pas encore standard par ailleurs).
Si tu présentes ces notions, tu dois alors expliquer quand utiliser quel type. Et franchement, c'est un sujet assez avancé.
D'où le choix de ne pas en parler.

Citation : R@hl43

les vectors : il est sûrement prévu d'en reparler mais peut-être parler de at() dés le début ?

at() est très peu utilisé. De plus, pour pouvoir l'utiliser correctement il faut connaître les exceptions. Donc ce n'est pas possible à ce stade. Mais cela apparaîtra plus tard.

Citation : R@hl43

le TP : peut-être exiger un peu plus du zéro. Un zéro trop avide de découvrir la suite réalisera le TP mais rarement les améliorations. Le TP en lui même étant pas très long, pourquoi ne pas demander quelques autres "fonctionnalité" dès le début ?

Chacun est libre d'apprendre de la manière dont il souhaite. Il est indiqué à mainte reprises qu'il faut pratiquer. Le lecteur est donc incité à faire les améliorations. On ne peut de toute façon pas forcer le lecteur à pratiquer.

Merci à tous pour vos commentaires.

<edit>
À propos de at() dont certains on parlé au dessus:
- je ne m'en sers jamais -> trop cher, et surtout aucun sens (une erreur de borne dans mon code == une erreur de programmation, pas un problème de contexte en vrac)
- il nécessite en effet de connaitre les exceptions
- ne vous laissez pas déformer par un langage que je ne citerai pas qui incite à claquer des exceptions sur les erreurs de programmation au lieu d'assertions.
</edit>

Bonnes initiatives (oui au pluriel! :))

I.1.
a- Premier passage éclair, je me suis déjà étendu dans des forums sur le sujet dans le passé, je fais court: Je considère la dichotomie haut/bas niveau complètement désuète. Et encore plus quand on envisage un langage multi-paradigmes comme le C++. Aujourd'hui, je vois un langage comme offrant une panoplie d'outils. Ces outils peuvent se regrouper par familles, et dans chaque famille un langage va aller plus ou moins loin : accès vers le hard, support de la PpC, gestion automatisée de la mémoire, collecte des ressources, prog fonctionnelle, support de la généricité/OO (points de variabilité/communs de façon plus générale), etc.
Cela me gêne d'autant plus que la liste pourrait laisser croire que Java serait plus haut niveau que Python ou pire Ruby, alors qu'il ne dispose même pas de certains possibilités haut niveau qu'offre le C++ (PpC native, boost.unit).
Bref, une dichotomie qui ne veut plus dire grande chose aujourd'hui.

b- avantages: il a la portabilité des sources (à quelques précautions près). On pourrait aussi dire qu'il est compilé (erreurs détectées au plus tôt).
Cette liste d'atouts me perturbe. Je comprends pourquoi il y en a une ceci dit. Une liste de faiblesses il faudrait peut-être également ?

c- Le passage C -> C++ n'a pas été direct, il y a eu d'autres influences entre temps. Ne serait-ce que celle du Smalltalk (IIRC, à vérifier)

d- bonus du C:
- the standard binaire -> pas d'ABI pour le C++ ; sans parler des problèmes de versions différentes dans l'implémentation de la SL, ou des détails internes de vtables
- langage plus simplifié => plus facile à supporter => on aura avant tout des compilos C sur les plateformes exotiques
- tradition


I.2.
a- g/linux/s/vi/vim
Il y a bien une différence -- et je compile (:make) et débugge (pyclewn) depuis (g)vim quand je suis sous linux d'abord

Citation : Nanoc

Citation : R@hl43

les types de variables : au moins nommer les quelques autres les plus connus même si ils sont moins utilisés : float, long long...)

C'est vrai, ces types existent. Mais ils n'ont que très peu d'intérêt lorsqu'on débute. Si tu en es à devoir gagner de la place en mémoire en utilisant des float à la place des double, c'est que tu n'est plus un débutant. De même pour les short ou les long long (pas encore standard par ailleurs).
Si tu présentes ces notions, tu dois alors expliquer quand utiliser quel type. Et franchement, c'est un sujet assez avancé.
D'où le choix de ne pas en parler.

Je partage l'avis de Nanoc. Cependant, quid d'une utilisation par mégarde de ces types non présentés dans le cours?

Je vais de ce pas lire la partie I et ferais certainement d'autres commentaires par la suite. Toutes mes félicitations pour la création de ce nouveau cours

I.3-
a- <iostream> n'est pas une bibliothèque.
Il y a une erreur de vocabulaire qui va faire que de temps à autre des débutants vont se faire bacher sur les forums pour avoir employé un mot de travers. [phénomène récurrent que j'ai déjà pu observer : certains qui ont franchi une première étape tapent sur ceux qui arrivent en boitillant derrière eux... ]

-> iostream est un fichier d'en-tête provenant de la bibliothèque standard du langage. Il définit des moyens pour interagir avec l'écran et le clavier (mal dit)
Et en plus, je vois que le quizz continue à enfoncer le clou de travers.

b- "Tous les programmes ont au moins une fonction qui s'appelle "main""
Euh. Non, pas "au moins". "au moins et au plus". Ils ont nécessairement une (et une seule) fonction principale : point d'entrée dans le programme.

c- "Le rôle de cout (prononcez "ci aoute") est d'afficher un message à l'écran. C'est ce qu'on appelle une instruction."
Attention, il est vite arrivé de lire de travers et de croire que c'est cout l'instruction.
[...] Ah ah! le quizz parle de l'instruction cout. Donc non. cout n'est pas une instruction !

d- +1 pour le conseil d'éviter les accents.

e- Cela fait quelques temps que je me pose la question "endl ou \n ?". Pour diverses raisons, nombre de caractères tapés, efficacité, je tendrais à privilégier \n. endl a une sémantique forte, et il fait parti du template du hello-world de C::B. Donc soit.
[Hum ... Je vois que AC++ utilise endl (avec std:: en fait), PPPuC++ utilise \n (et ignore complètement les espaces de noms au démarrage -- il serait plus un bouquin d'initiation à la programmation qu'au C++ d'après JMB sur dvpz ; je n'ai pas encore eu^Wpris le temps de le lire sérieusement), et JmL est à la maison.]

f- Une école tend à préférer // même pour les commentaires longs : celle qui utilise /* */ pour inhiber des blocs de code et qui se refuse à utiliser #if 0 à cause d'EDI ne sachant pas les colorer comme il se doit.
Maintenant, pour les capsules doxygen, j'avoue utiliser /** et non /// -- mais j'utilise #if 0 aussi, alors du coup ...
Ah. Je sais pourquoi "long" / "court" m'a perturbé : j'utilise /* */ pour des commentaires hyper-courts, et finis avant la fin de la ligne. Du genre:

/*virtual*/ int C::f() const { return 42; }
sur /*static*/ S* S::instance() { ... }

g- oui, important de signaler que l'on ne doit pas *tout* commenter.

EDIT: ah. C'est vrai que l'on ne peut pas enchainer les posts....


I.4-
a- "Utiliser la mémoire"
Ce titre me gêne. Je comprends d'où il vient : analogie avec les calculettes.
Mais il risque de décontenancer ceux qui ont une expérience avec d'autres langages et qui auront déjà croisé la notion de variable.

b- j'aime bien l'analogie pour les types (livre, bouteille, ...)

c- concernant l'interdit "_nomzero", en fait c'est plus subtil que cela.

d- les bornes pour int sont fausses. Quitte à donner des bornes, il faudrait préciser que celles données ne sont valides que pour les machines personnelles d'aujourd'hui. Et qu'elles sont susceptibles de changer avec les prochaines générations de processeurs/compilateurs.
Mais vu que long, et short ne sont pas abordés, pourquoi donner leur domaines d'implémentation ? (oui, c'est bien un néologisme)

e- un choix étrange que de préconiser le style "T v(42);". Pourquoi pas.

f- "il est toujours bien de mettre un commentaire pour expliquer à quoi va servir la variable."
Bof. Il est toujours bien d'avoir une variable dont le nom est si fort qu'il nous permet de nous passer d'un commentaire expliquant son role et/ou son contenu.

g- Très bof le conseil de mettre toutes les variables sur la même ligne.

h- On ne parle d'allocation de mémoire que pour les variables du free-store (avec un /dynamic storage duration/)
Au sens général, j'ai l'impression que l'on parle de stockage, mais pas d'allocation. Pas pour la pile. "On va réserver un espace où stocker la variable (pour la durée du bloc/fonction courant(/e))"

i- il faudrait prévenir ne pas oublier les () pour les déclarations non intialisantes -- vu que le style parenthèse est préconisé.

Tout comme lmghs, j'ai remarqué que les explications autour de la "bibliothèque iostream", de la "bibliothèque standard" et de son "espace de nom std" n'était pas claires. Une explication de ce qu'est une instruction en C++ aurait sa place dans le chapitre 3 au paragraphe "Explications du premier code source".

J'ai aussi remarqué que les expressions "code"/"code source" étaient utilisées dans les 3 premiers chapitres sans avoir été proprement définies.

Je vous réponds déjà au sujet des chapitres sur lesquels j'ai travaillé plus activement. Je garde le reste en tête pour en discuter avec M@teo par la suite quand on aura accumulé plus de remarques.

Chapitre I.4 donc.

a- On voulait introduire la notion en douceur et donc ne pas effrayer le lecteur (considéré comme débutant) avec un mot nouveau dès le premier vrai chapitre technique du cours. Et comme tu l'as relevé, c'est aussi pour l'analogie avec la calculatrice.

b- Merci

c- Et je t'avouerais que je ne connais pas la formulation exacte tirée de la norme. Mais les noms commençant par _ sont réservés pour la SL avec quelques subtilités. Pour ne pas entrer dans les détails, j'ai mis une règle un poil plus (trop) large.

d- J'ai mis les bornes pour différentier les int et les unsigned int. Même si il est vrai que ce n'est pas la différence la plus intéressante. Je vais néanmoins ajouter une remarque pour indiquer que ces nombres sont là à titre indicatif et qu'ils peuvent varier selon la machine. Ou peut-être même supprimé ces bornes. A voir.
Mais je doute quand même que les gens débutent en C++ sur des micro-processeurs ou le int est codé sur 16 bits.

e- Nous avons préféré la notation T a(42) pour différentes raisons. La principale étant qu'elle permet de ne pas introduire de notation différente entre les types PODs et les objets comme string ou vector que nous introduisons avant d'aborder la notion de constructeur.

g- Je suis du même avis que toi. Cependant, on trouve des quantités de sources sur le web où c'est fait. Il fallait donc quand même introduire la notation. Je vais peut-être tourner la phrase de sorte que l'on ne croie pas que c'est la meilleure manière de faire.

h- J'ai utilisé "allocation" ici en prévision du chapitre sur les pointeurs. Il est clair que l'"allocation" en temps que tel n'a pas lieu à ce moment là du déroulement du programme, mais plus certainement au début de la fonction ou lorsque des registres seront libres. Mais c'est très complexe. Je voulais garder le tout le plus simple possible en identifiant les deux parties, demander de la mémoire (peu importe comment et où) et remplir la zone mémoire.

i- Là, je ne te suis pas.

int a();

est faux. Ca ne déclare pas une variable sans l'initialiser mais une fonction. Ou alors je n'ai pas compris ce que tu voulais dire.

Ah c'est pour ça cette règle sur le underscore ! Car moi il m'est arrivé très souvent de mettre commencer toutes mes variables membres par un underscore (comme ça ils sont triés à la fin ou au début par l'auto complétion) et je me disais "ce n'est pas vrai vu que j'ai souvent fait ça !".

Je pense que ce lmghs veut dire à propos de int a(); est justement d'insister sur le fait que cela est faux. Car, avec new par exemple, ceci est correct :

int * a = new int();
Classe * b = new Classe();

J'ai eu moi même cette erreur au début : voir déclarer des Objets sans allocation dynamique avec le constructeur par défaut en mettant ().
Une précision serait donc bien la bienvenue je trouve (dans le même avis que lmghs si c'est ce qu'il voulait dire).

I.4.h-
Préférez vraiment les notions de stockage (ou autre mot qui vous parle) à celle d'allocation ici. Le mot "allocation" est très précis en C et dérivés. N'étendez pas son sens unilatéralement.

I.4.i-
Oui c'est faux. Justement. Attention aux zéros qui se contenteront juste de vider ce qui est dans les parenthèses, mais pas les parenthèses. C'est une faiblesse du langage, et une erreur d'inattention qui arrivera vite. Surtout chez ceux qui n'ont pas encore les outils pour connaitre et comprendre cette écriture chargée d'histoire.



I.5-
a- § "D'autres variables"
Ici, initialiser les variables lues à une valeur qui est celle que l'utilisateur est sensé saisir est une très mauvaise idée.
La lecture du tuto va donner une mauvaise idée au zéro. Mettez plutôt un "lecture-foirée" et -1 -- tout en gardant 3.14 en valeur tapée au clavier. Vous pourrez alors revenir en temps utile sur l'importante habitude à prendre qui est : "on doit toujours tester l'état du flux après lecture".

b- on assigne en justice, mais on affecte une valeur à une variable.

c- modulo n'existe que pour les nombres entiers, oui. => valable aussi pour char, short, long, etc

d- "[...] des variables non modifiables. En termes techniques, on parle de constantes"
Hum ... Je sais que je verse dans le néologisme, mais attention. Nous avons la constante connue à la compilation, et le résultat de calcul qui n'est connu qu'à l'exécution, mais dont on veut la valeur figée à tout jamais.
(j'ai tendance à utiliser "variable non modifiable" pour désigner ces fausses constantes. Pourquoi je fais le distinguo ? Parce que j'utilise de plus en plus const pour signaler qu'une variable n'évoluera plus, et que les utilisateurs d'outils de vérification de style n'ont pas intérêt à venir m'enquiquiner pour me dire que le nom de la variable devrait être EN_MAJUSCULES car ce n'est pas une constante de compilation.)
<edit>c'est probablement à moi de trouver un autre terme...</>

e- "resultat = a + b;"
Nous sommes en C++, assumons ses styles recommandés qui ont du sens => "/*const*/ double resultat = a + b;" (ou "/*const*/ double resultat(a + b);" pour rester dans le style du tuto)

f- Cela a été signalé ailleurs: le quizz utilise la pré-incrémentation, mais le tuto ne traite que de la post-incrémentation.
(je ne sais pas s'il faut traiter de leurs effets de bord)

g- Dans le thème math, il y a un petit exo relativement simple : calcul du ppcm/pgcd. Voire introduire le projet euler pour les exos qui ne nécessitent pas encore des tableaux.
Ah! Les structures de contrôle, et la définition de fonctions n'a pas encore été introduite. Suis-bête! J'y reviendrai peut-être une fois le chapitre correspondant au fonctions lu.

I.6-
a- hum ... J'aurais introduis ce chapitre avant les opérations mathématiques. À cause du I.5.g- justement.

b- comme c'est formulé, on pourrait croire que le switch n'existe que pour des raisons de clarté de code.
Il existe aussi et surtout pour des raisons d'efficacité -- du moins en C & descendants. Il ne ferait pas de mal de rappeler qu'il n'est pas utilisable sur les chaines non plus (contrairement aux caractères -- qui sont des entiers)

c- "bool parent(false); parent = (nbEnfants > 0) ? true : false;"
Oui mais non.
"const bool est_un_parent = nbEnfants > 0;"
Les problèmes:
- "parent" -> nommage de la variable qui nécessite un commentaire d'explication de son rôle
- si (cond == vrai) => v = vrai, sinon v = faux" est d'une lourdeur abominable.
- déclaration et définition en deux temps, en passant par une valeur intermédiaire qui ne sert à rien

Je ne suis pas fan de présenter l'opérateur ternaire à des débutants.
Mais quitte à la présenter, prenez un autre exemple dont le résultat ne sera pas un booléen. Un exemple ? Hum ... [5 minutes plus tard]
cout << "Vous avez " << nbEnfants << " enfant" << (nbEnfants > 0 ? "s" : "") << endl;
Et en plus, c'est un cas d'utilisation où l'on s'intéresse effectivement plus à la valeur finale qu'au test => en accord avec l'utilisation de l'opérateur ternaire.

d- "Contrairement aux conditions, les 3 (boucles) sont assez fréquemment utilisées"
Comment ça ?
1- c'est quoi une "condition" ? Un booléen ? On ne peut utiliser une boucle sans revenir à un booléen. Un if ? Les if sont très utilisés. Et puis while n'est qu'un if-goto.
2- peu importe les fréquences, non ? Cette chère Ada nous l'avait démontré : pas de programme qui serve à quoique ce soit sans sauts-conditionnels.

e- le for -> le type du compteur va dans le for! Pas avant. Nous sommes dans un tuto de C++, pas dans un tuto de C pre-99. Ce n'est pas une possibilité, c'est un conseil appuyé.

f- Le test "<= 10" me parait une mauvaise idée. La forme canonique c'est [0 ; 10 [ en C et C++. C'est ainsi que l'on boucle 10 fois, sur les 10 éléments d'un tableau.
Les premières choses que l'on voit tendent à rester. Et là plus tard, il faudra leur faire oublier <= pour leur apprendre à itérer dix fois, et rendre la chose compatible avec les tableaux natifs (au sens large -- i.e. non fortanisés) 0-indexé.

(Message posté sur la news mais traitant plus du contenu donc je suppose qu'ici est un endroit plus approprié pour obtenir des réponses)

Quant aux commentaires qui parle de trop "condensé" je trouve aussi mais le pense que la présence de Travaux Pratiques entre certains chapitres enlèverait fortement cette condensation ! Dans le tuto C, il y avait beaucoup de petits exercices entre les chapitres qui aidaient vraiment beaucoup à la compréhension (c'est certain !).

Sinon je trouve qu'il devrait être possible de continuer à apprendre le C++ en connaissant déjà le C (de plus, le travail est déjà fait), le nouveau tuto serait bien entendu le principal.

un peu comme ça, il existerait 3 "morceaux" au tuto C++ :

• Morceau 1 : [Bases sans prérequis C (gros morceaux)]
• Morceau 1C : [Bases avec prérequis C (morceau beaucoup plus petit, "nouveautés C++" comme avant)]
• Morceau 2 : [POO, Qt, ancien tuto de Nanoc + nouveautés (très gros morceau)]

Ce qui permettrait de faire un des deux chemins suivant : (avec grande préférence pour le deuxième sur le C n'est pas connu)

• tuto C -> Morceau 1C -> Morceau 2
• Morceau 1 -> Morceau 2

(Ou bien le Morceau 1C serait un tuto à part aiguillant sur le "Morceau 2" à sa fin).
Notamment car la présence de différentes approches peut parfois être bénéfique , et aussi de montrer qu'il existe réellement un lien entre les deux langages (je sais qu'une critique a été faite comme quoi les débutants avaient des confusions là dessus mais bon ).

I.7-
a- vocabulaire type:
- argument <-> paramètre réel
- paramètre <-> paramtre formel
(du moins c'est ainsi qu'il emploient argument et parameter en VO.)

b- "int valeur(0); //On cree une case en memoire.
valeur = nombreRecu + 2;"
C'est vraiment une mauvaise pratique. Ne les poussez pas à la commettre.

c- quitte à doxygener le cartouche de la fonction (/**), autant respecter la syntaxe de doxygen, non ? (-> @param, @return, etc)
(Ou alors un seul /*)


I.8-
a- Les tableaux ne sont pas passés par référence. Car on peut les passer par référence, et c'est le seul moyen de faire transiter la taille avec.

template <typename T, size_t N> void f(T (&nom)[N]) // si je me souviens bien de la sytnaxe

C'est l'adresse du tableau qui est passée.
Hum si seulement std::array était déjà standard... Il faudrait presque attendre de voir les pointeurs pour parler des tableaux statiques et des fonctions.
Et on peut renvoyer un tableau à quelques détails près (std::array qui est copiable je crois, tableau dynamique, tableau statique membre de classe).

b- "int taille; //Une variable pour contenir la taille du tableau
taille = tableau.size();"
Non. Une ligne!

c- appeler vecteur "tableau dynamique" me gêne. Certes il est complètement dynamique, mais cette expression désigne autre chose en vrai.

I.9-
a- "while (std::getline(...))" est la seule façon correcte de lire les lignes d'un fichier. Certainement pas "while(flux) { getline(); use(line); }"
Toute tentative de lecture sur un flux doit être testée pour valider que l'on a bien lu quelque chose.

b- je n'ai jamais compris pourquoi std::*fstream::open() persistait à être utilisé en C++ ...
RAII! (au sens premier: initialiser à la déclaration; jamais de données dans des états inutiles). Donnez leur de bonnes habitudes dès maintenant.
(C'est la même histoire que les "int i; i = f(42);")

c- les flux étant RAII au sens détourné (RRID), close est une fonction implicite en C++. On ne va l'utiliser que quand on a besoin d'une fermeture prématurée à cause de blocs mal venus pour rendre la chose implicite.

-> ce que je veux dire par c- et d-, montrez plutôt la façon plus dans l'esprit C++, et évoquez à la fin qu'en fait il existe les autres fonctions.

d- il faudrait les prévenir comment on enchaine un >> avec un getline. C'est un problème qui arrivera vite.

e- une inversion tellg/tellp : p=put => ostream, g=get => istream

Citation : Nanoc

I.4.a- On voulait introduire la notion en douceur et donc ne pas effrayer le lecteur (considéré comme débutant) avec un mot nouveau dès le premier vrai chapitre technique du cours. Et comme tu l'as relevé, c'est aussi pour l'analogie avec la calculatrice.

I.4.d- [...]
Mais je doute quand même que les gens débutent en C++ sur des micro-processeurs ou le int est codé sur 16 bits.

La question est "qui sont les débutants ?". Des étudiants ? Des lycéens ? Des professionnels qui parce qu'ils connaissent Java seront bien capables de s'occuper de la TMA d'un projet embarqué qui vient d'être gagnée ?
Donner des bornes en vérité absolue est un détail idiot et vite corrigé qui sera repris par des détracteurs du tuto. Je vois deux options:
1- Ne pas donner de bornes vu que de toutes façons, on ne parle pas des autres types entiers
2- "Sur votre machine à la maison, les limites des int et de uint sont:"


I.8-
d- Une question sur le forum m'a fait voir un problème que je n'avais pas regardé : En C et en C++, les tableaux sont conventionnellement organisés par ligne.
->T[Y][X] et non le contraire. C'est la convention la plus répandue.

Je ne réponds pas, mais je prends bonne note de tout ça. J'ai apporté quelques corrections de coquilles comme I.5.a, I.5.b, I.5.c ou I.9.e.

Des réponses à tes remarques et/ou des modifications plus conséquentes du cours vont suivre.

Je m'en doute.
Courage, vous avez déjà bien avancé.

SFML serai mieux que Qt pour la pratique car il déforme le C++.
Faire un autre Big tuto sur Qt plus transformer la pratique vers SFML serai énormément de travail mais aiderai beaucoup d'entre nous et permettrai aussi d'appronfidire Qt : Qxml, Qsql, Qfile.

Bonsoir tout le monde !

Voilà, cela fait maintenant des mois que je lis les tutos du site et que j'admire la qualité de ceux-ci.
Je me suis néanmoins inscrit pour poster une petite idée "d'amélioration" (c'est un bien grand mot).

Le tuto traitant du C++ ayant été refait en partie, je ne sais pas si cela a été fait, mais cela serait utile je pense d'inclure un lien vers la section SDL du tuto du C, en plus d'ajouter quelques mots, parce que la SDL est un outil formidable et incontournable.

Je suis parfaitement conscient que tout ce qui est dis sur la SDL dans le tuto du C est directement utilisable en C++ (pour peu qu'on change les inclusions etc pour les adapter au langage C++). C'est pour cela que je trouve inutile de refaire un tuto SDL pour C++.

Bref, je suis ébahi du travail que fournit cette communauté pour les nouveaux, et moi le premier.

Je souhaiterais que ce site ne meurs jamais, animé par des passionnés qui savent ce qu'il faut pour être pédagogique.
Je vous dis : Merci !

Je vais modifier prochainement le chapitre sur les fichiers pour donner dès le départ la version RAII. De même que la mauvaise habitude de ne pas initialiser directement les variables avec les bonnes valeurs.

Concernant les remarques de lmghs, est-ce que tu pourrais détailler ce que tu veux dire par ta remarque :

Citation

I.7-
a- vocabulaire type:
- argument <-> paramètre réel
- paramètre <-> paramtre formel
(du moins c'est ainsi qu'il emploient argument et parameter en VO.)

Merci !

J'ai juste pinaillé sur le vocabulaire. Il me semble avoir voir un "argument" désignant un paramètre formel.
-> Parameter_(computer_science)#Parameters_and_arguments
-> Paramètre#Param.C3.A8tre_effectif

Et pour en revenir au C++ -> http://www.devx.com/tips/Tip/13049

Oui alors là, c'est effectivement du pinaillage. On en est pas non plus au stade de former les gens à pouvoir lire la norme.

Non. Mais utiliser des mots précis aide toujours pour discuter ensuite.

Salut , je pense que vers la fin de " modifier le contenue d une variable" , dans le chapitre"une vraie calculatrice "
il serait bien de dire que double permet de faire les opération a virgule , sinon si je les loupé ou vous le dite quel que part me le dire ...( j ai pas fini de lire le chapitre donc ... mais placé la sa donnerait un sens ...

C'est indiqué dans le chapitre précédent. Il y a un tableau qui montre que double correspond aux nombres à virgule.