Monsieur le professeur,
s'il est très courageux de votre part d'essayer d'apprendre à programmer à vos étudiants, il serait plus que temps que vous mettiez vos connaissances du C++ à jour : cela fait maintenant près de vingt ans que la classe std::string existe, et qu'il est très largement préférable de l'utiliser en lieu et place de ces horribles char *.
De même, cela fait tout ce temps qu'il est conseillé d'utiliser la classe std::vector ou ( depuis trois ans, ce qui fait un bail en informatique) la classe std::array pour les tableaux dont on connait effectivement le nombre d'éléments à la compilation en lieu et place des tableau "C style".
A moins, bien sur, que vous ne vouliez leur apprendre à programmer en C

Mais, dans ce cas, vous seriez aimable de ne pas faire passer votre cours pour un cours de C++, car ce sont bel et bien deux langages totalement différents rendant toute confusion extrêmement dangereuse.
Notez enfin que vous devriez sérieusement veiller à la cohérence de votre énoncé : si toutes les données sont de type double, il semble peu cohérent de renvoyer un total sous la forme d'un float : bien que visiblement sans grande incidence dans votre exercice (après tout, la précision des montants n'excède normalement pas la deuxième décimale), cela pourrait avoir pour effet de faire perdre des données importante pour tout besoin nécessitant une précision plus importante.
Un compilateur ben réglé aurait d'ailleurs attiré votre attention sur ce fait au travers d'un avertissement, mais, peut-être estimez-vous savoir mieux que le compilateur ce qui peut poser problème

Permettez moi d'émettre de très sérieux doute sur le sujet.
Pouvez vous en outre prendre note du fait que la notation polonaise a été abandonnée depuis bien longtemps déjà (du moins en C++), tant il a été prouvé qu'elle apportait vraiment rien --surtout lorsque l'on utilise les types adéquats

:
- chNom pourrait très bien s'appeler nom (ou Nom, si vous préférez), on se doute très bien que c'est une chaine de caractères
- idem pour chLigne qui pourrait s'appeler ligne (ou Ligne)
- idem pour chMonArticle, qui, pour la cause, devrait s'appeler nomArticle (ou NomArticle, pour respecter vos conventions)
- tabMontant pourrait s'appeler montants (ou Montants) : le pluriel nous indiquerait clairement qu'il s'agit d'un tableau
- il en va de même pour tabEnregistrement qui devrait s'appeler enregistrements (notez encore une fois le pluriel)
- Enfin, on se fout pas mal que CEnregistrement soit une classe (une simple struct ferait d'ailleurs l'affaire, pour la cause). Nous pourrions la nommer Enregistrement sans que cela ne pose de problème
Notez enfin que l'idéal est de choisir une convention de nommage qui permette d'éviter les erreurs entre les types et les noms de variables / de fonctions. La convention de nommage de la STL n'est -- très clairement pas forcément la meilleure, mais une chose est sur : les noms de fonctions et de variables sont tout de suite beaucoup plus repérables quand ils sont écrits en lowerCamelCase (ou tout en minuscules) et les types définis par l'utilisateur sont tout de suite plus repérables lorsqu'ils sont écrits en HightCamelCase.
Au fait, saviez vous que la seule différence entre le mot clé class et le mot clé struct réside dans l'accessibilité appliqué par défaut (comprenez : avant que l'on ne croise le premier spécificateur d'accès)

privée pour le mot clé class, publique pour le mot clé struct. Mais, en dehors de cela, il n'y a absolument rien que l'on puisse faire avec l'un que l'on ne puisse pas faire avec l'autre.
Enfin, bref : je ne saurais jamais insister assez sur l'absolue nécessité que vous auriez à mettre vos connaissances à jour, car, dans la situation présente, vous ne serez jamais en mesure de former vos étudiants à fournir du code correct et un minimum robuste.
Bien à vous,
DUNSKI Philippe
Expert C++, expert qualité du développement
auteur du livre Coder efficacement -- bonnes pratiques et erreurs à éviter en C++
Partager