Discussion :

[senvedgi]

bonjour,
J'écris toutes mes fonctions sur ce schéma:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
//etud2
#include <iostream>
#include <cstdlib>
#include <fstream>
#include <windows.h>
#include <string>
#include <vector>
#include <sstream>
#include <stdio.h>
#include <istream>
 
using namespace std;
 
string FcAB(string A,string B)
    {//fc
    cout<<"     e..  Fc  ..e"<<endl;
    cout<<"     fcL1"<<endl;
 
     cout<<"     fcLn"<<endl;
    cout<<"     z.. Fc   ..z:"<<__func__<<endl;
    return "";
    }//fc
 
int main()
{
cout<<"e--I--e"<<endl;
string a,b;a="A";b="B";
string ab=FcAB(a,b);
//cout<<"s "<<a<<endl;
//cout<<"s "<<b<<endl;
cout<<"Z--I--><E>";cin.ignore();
}

Et vlan!Elle sort mal.
Que manque t-il?
Vos lumières me seront précieuses.

[ternel]

seams legit
"Elle sort mal", dis-tu? lui as-tu indiqué où se trouve la porte?
plus sérieusement, quel est le symptome?

Ah, tiens, j'ai ici une boule de cristal, testons donc.

Je vois … que tu ne sais pas ce qu'est un code minimal, vu que tu inclues pas moins de neuf en-têtes là où seul iostream suffit.
Par ailleurs, par le jeu des inclusions chainées, tu n'a pas besoins de istream si tu as iostream, et stdio.h est remplacé par cstdio (stdio.h est déprécié et pourrait disparaitre)

Je vois … que tu ne sais pas ce qu'est une fonction void, vu que FcAB retourne "" sans raison aucune.

Je vois … que tu ne connais pas la différence entre affectation et initialisation:
string a,b;a="A";b="B"; se code normalement, string a="A", b="B";, ce qui signifie que, toi, tu construit deux strings, puis change leurs valeurs, au lieu de les construire tout de suite avec les bonnes.

Je vois … que tu ne fais pas de return dans main, ce qui n'est pas absoluement grave, mais mérite d'être noté.

[senvedgi]

bonjour!
Merci.
Les ent^tes c'est pour être sûr de ne pas en oublier pour le reste d'autres fonctions
Je sais la différence entre init et affec.,merci.
C'était la rubrique "détails".
Quand je dis sort mal le message est <xx.ex a cessé de fonctionner etc...>.
J'ai rajouté le <return "";> dans la fonction return que j'avais oublié..
..Et qui fait que la fonction marche enfin..ici..
1)dans un but didactique perso j'écris string x; ou ""; et sur la ligne suivante
x="qqchose";.c'est perso et c'est comme çà!
2)je cite< pas de return dans main>.Je ne vois ce mot-clef nul part ailleurs.
3) j'essaie de faire fonctionner ma fonction avec son contenu , un tableau que j'ai simplifié pour cette étude et la fonction marche.
4) je me demande où mon écriture pêche dans la vraie vie.
Merci pour cette réponse.
Au prochain post je marque résolu mais c'est un résolu provisoire car je suis en étude.
Cordialement.

[ternel]

Pour le main, le return est "un peu" facultatif, et permet de définir explicitement la valeur de sortie du programme. Ne pas le donner se traduit par "ce que l'environnement d'exécution trouve acceptable", en général 0.

Pour les initialisations, tu va pleurer le jour où tu verras le RAII. Contrairement au C, en C++ on ne déclare rien en avance.

Parce qu'en réalité, les déclarations de variables n'existent pas, sauf si elles sont extern et à portée globale (ou juste dans un namespace).
à chaque fois que tu écris Type t; le constructeur par défaut de Type est appelé à l'emplacement alloué pour t.
Pour un simple int, c'est rien du tout, mais pour d'autre type, ca peut être monstrueux. Voire ne pas exister, si le type n'est pas default-constructible, ce qui arrive régulièrement dans du code réel.

Ton std::string s; construit effectivement string s("");.
L'affectation peut avoir été supprimée pour certaines classes, ou être lourde de charge.

Tout cela n'est pas du "détail", mais bien des conseils pour ne pas avoir trop de problèmes par la suite. Les difficultées pratiques sont suffisantes, n'ajoute pas les mauvaises habitudes.

[koala01]

Salut,

bonjour!
Merci.
Les ent^tes c'est pour être sûr de ne pas en oublier pour le reste d'autres fonctions

Le but des en-têtes est, justement, d'éviter de se "trimballer" ce dont on n'a pas besoin car la directive #include va littéralement copier le contenu des en-têtes avant de les parser.

Plus tu rajoutes des en-têtes, plus le compilateur aura du boulot pour les lire, et plus la compilation sera lente

Il est donc recommandé de n'inclure que les en-têtes dont tu as besoin au moment où leur besoin s'en fait sentir, et ce d'autant plus qu'il y a un jeu "d'inclusions en cascade":

• <iostream> inclut d'office <istream> et <ostream>
• <cstdlib>, <windows.h> et <stdio.h> (qui devrait etre <cstdio>) sont d'office incluts par au moins l'un des autres fichiers d'en-tête que tu as ajouté (sans doute <string>
• <string> est, effectivement, nécessaire pour le code que tu présente
• <sstream> n'est nécessaire que si tu veux faire une conversion chaine<-->autre chose, mais, dans le cas présent ne sert à rien
• <vector> n'est utile que lorsque tu envisage de manipuler un... std::vector, qui n'apparait nullement dans le code présenté

1)dans un but didactique perso j'écris string x; ou ""; et sur la ligne suivante
x="qqchose";.c'est perso et c'est comme çà!

Dans un but didactique, tu devrais prendre directement les bonnes habitudes, c'est à dire:

1. une instruction par ligne
2. une déclaration de variable par ligne
3. initialiser autant que possible directement tes variables avec les bonnes valeurs.

Le code que tu présentes

Code :

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

string a,b;a="A";b="B";

ne respecte aucune de ces règles de base

Il devrait ressembler à

Code :

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

1
2
string a("A");
string b("B");

et serait

1. plus court (vu que tu semble paresseux, ce qui est une bonne chose en informatique )
2. plus lisible pour tout le monde (un code est bien plus souvent lu qu'il n'est écrit / modifié )

2)je cite< pas de return dans main>.Je ne vois ce mot-clef nul part ailleurs.

le fait est que le prototype de la fonction main est

Code :

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

int main()

ce qui signifie:

• la fonction ne prend pas d'argument (dans cette version-ci de main, car il y en a d'autres
• la fonction renvoie au système d'exploitation un entier pour qu'il puisse savoir si l'application s'est terminée correctement. Les valeurs attendues par le système d'exploitation sont
  
  • 0 si tout se passe bien
  • autre chose si "quelque chose à foiré"
  • sur certains système d'exploitation : 2 s'il y a eu des avertissements
  • 3 pour exprimer le fait qu'il y a eu une erreur que l'application a "rattrapée" pour terminer sans planter (mais il y a donc bel et bien eu une erreur

4) je me demande où mon écriture pêche dans la vraie vie.

Dans la vraie vie

En travaillant dans mon équipe, tu passerait par la fenêtre si tu osais me présenter un code pareil :

Comme je te l'ai signalé plus haut, un code est beaucoup plus souvent lu qu'il n'est écrit / modifié.

Sa première qualité, avant même de faire ce qu'on lui demande, doit donc être d'assurer une lecture facile. Au moins, s'il ne fait pas ce qu'on attend de lui, on pourra facilement trouver pourquoi il ne le fait pas, et y apporter une solution

J'ai dit plus haut que la paresse est une bonne chose en informatique, dans le sens où elle va t'inciter à ne pas faire deux fois des choses qui pourraient ne l'être qu'une fois, mais il y a toujours cette limite de "lisibilité aisée" à ne pas dépasser:

Pour assurer la lisibilité aisée, il faut impérativement prendre conscience du fait que le meilleur moyen de commenter le code est de faire en sorte que toutes les variables, toutes les fonctions, tous les types que l'on définit indiquent explicitement ce que l'on attend d'eux

Il n'est pas plus fatiguant de nommer une fonction fonctionAB, ou mieux encore doNothingWithAnorB que de la nommer fctAB, mais cela permettra au lecteur du code d'avoir une idée précise de ce que fait la fonction, sans avoir à aller "voir dedans" pour se rendre compte qu'elle n'utilise en réalité ni a, ni b

La complétion automatique du code aidant, il ne sera même pas plus fatiguant d'utiliser cette fonction bien nommé que d'utiliser "fctAB"

Pour assurer la lisibilité aisée, il est primordial que l'on ne risque pas de "passer à coté" de quelque chose...
Il est vrai que l'on peut déclarer autant de variable du même type en séparant leurs identifiants par des virgules, mais cela augmente le risque de "passer à coté" d'un des identifiants...

On risque donc de perdre "bêtement" du temps à se demander "mais de quel type est cette variable" ou bien "mais où cette de variable prend-elle cette valeur"lors de la lecture, simplement parce que l'identifiant est "noyé" parmi une foule d'autres

Il y a donc deux règles à respecter dans "la vie de tous les jours":

1. une déclaration de variable par ligne
2. une instruction (quelle qu'elle soit) par ligne

Ce n'est pas plus fatiguant, mais c'est plus lisible

Ensuite, même si l'on considère que les optimisations prématurées sont les chemins de tous les enfers, le fait d'éviter les copies et les affectations inutiles est loin de représenter une optimisation prématurée

En travaillant comme tu le fais, tu as :

1. une construction (de chaine vide) pour a et pour b dans la ligne string a,b;
2. une affectation (qui passe par la construction d'une chaine, vu qu'il faut convertir ton const char * en std::string) pour a et pour b dans les lignes a="A";b="B";
3. une copie de a et de b lorsque tu les passes à fctAB car tu les passes par valeur

toutes ces constructions / copies / affectations prennent un temps bête et sont clairement de nature à "plomber" les performances

c'est la raison pour laquelle, il faut rajouter deux règles à suivre "dans la vie de tous les jours" :

1. définir les variables au moment de leur déclaration, autant que faire se peut
2. transmettre tout type complexe aux fonctions par référence (éventuellement constante, si la fonction ne doit pas le modifier)

fctAB (la mal nommée ) devrait être d'un prototype proche de

Code :

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

std::string fctAb(std::string const & a, std::string const & b)

car, bien qu'elle ait sémantique de valeur, la std:: string est bel et bien un type "complexe"

[ternel]

Ce qu'il y a de bien avec toi koala01, c'est que tu trouves toujours les bons mots pour dire les choses.
Après tes interventions, j'ai toujours l'impression d'être obscur et confus.

[koala01]

Ce qu'il y a de bien avec toi koala01, c'est que tu trouves toujours les bons mots pour dire les choses.
Après tes interventions, j'ai toujours l'impression d'être obscur et confus.

Merci

Je ne fais qu'essayer d'appliquer les principes que j'énonce dans les deux première lignes de ma signature

[senvedgi]

bonsoir,
21h je reprend le fil..
Merci pour la volée de bois vert.
Si je peux rassurer sur le nombre d'en-têtes c'est qu'elles y sont toutes à ce stade de mon programme uniquement pour me faciliter la tâche.J'ai toujours eu conscience qu'il ne faut y inscrire que celle(s) qui sont nécessaire(s).
Je vais simplifier car les unes étant incluses dans les autres(POO oblige) mais qui ailleurs qu'ici me l'aurait dit?
La vraie vie c'est mon code en vrai(pas celui que je vous ai soumis) et qui ne veut pas fonctionner mais à 20h55 j'ai trouvé la cause.
Je vais retenir l'écriture:
string a("A");
string b("B");
car explicite,concise,rapide en temps-machine rarement vu ailleurs qu'ici.
Le return dans main je laisse tomber:je suis pressé!
Mes fonctions s'appellent TOUJOURS FcXxxYyyy(...).
La cause de la mauvaise sortie c'était une incrémentation qui dépassait la limite implicite.J'avais cependant mis un cout<<lavariable<<endl; QUE JE NE LISAIS PAS.
Je relirai tous les soirs avant de me coucher cet ensemble de recommandations.
Merci à tous.

[koala01]

bonsoir,
21h je reprend le fil..
Merci pour la volée de bois vert.

Mais ce fut un réel plaisir...

Si je ne te l'avais pas dit, qui l'aurait fait

Comprends bien que l'idée derrière cette "volée de bois vert" n'était absolument pas de te rabaisser d'une manière ou d'une autre, mais plutôt de te faire profiter de l'expérience de "ceux qui ont fini par apprendre"

je suis persuadé que personne ne pourra te dire en te regardant dans le yeux qu'il n'a jamais commis ce genre d'erreur à ses débuts sans mentir effrontément.

Mais, l'expérience aidant, on finit fatalement par se rendre compte que les conseils des "vieux cons qui font la leçon" () sont vraiment justifiés

La vraie vie c'est mon code en vrai(pas celui que je vous ai soumis) et qui ne veut pas fonctionner mais à 20h55 j'ai trouvé la cause.

La vrai vie, c'est ton code quand tu devras te relire d'ici deux ou trois mois parce que tu veux apporter une évolution quelconque.

D'ici là, même toi, tu devra arriver à comprendre "aussi facilement que possible" ce que tu as écrit et qui te semble, pour l'instant, si limpide.

Sauf que, comme tu auras sans doute "pissé" plusieurs milliers de lignes de code d'ici là, que tu auras eu des soucis quotidiens, et que tu auras eu tout le loisir d'oublier pourquoi tu as fait ceci ou cela, ou quel était le but de telle ou telle fonction ou variable.

La vraie vie, c'est le temps que peuvent passer les intervenants sur ce forum pour apporter une aide aussi efficace que possible aux questions qui leur sont posées.

Mais tous les intervenants le sont à titre totalement gracieux et le font sur leur temps libre.

Si ton temps t'est précieux, celui des autres intervenants l'est tout autant

Leur fournir un code facilement compréhensible est en soi déjà une marque de respect envers leur implication

La vraie vie, c'est le travail dans une équipe de plusieurs programmeurs qui "travaillent chacun sur un problème particulier", mais qui, en fonction des disponibilités, doivent régulièrement reprendre le code de leurs collègues.

Tout cela, c'est la "vraie vie" avec à chaque fois une constante : il faut vraiment s'assurer que lorsque tu arrives sur un code que tu ne connais pas (ou dont tu as eu le temps d'oublier les subtilités), tu puisse comprendre au minimum les grandes lignes à la simple lecture du code, sans avoir à te poser de questions

Voilà pourquoi j'insiste énormément sur l'aspect de la lisibilité du code

Je vais retenir l'écriture:
string a("A");
string b("B");
car explicite,concise,rapide en temps-machine rarement vu ailleurs qu'ici.

Ce n'est pourtant que la simple utilisation correcte d'un constructeur connu pour faire partie de la classe std::string

Le return dans main je laisse tomber:je suis pressé!

Il est vrai que ca prend un temps fou que d'écrire un return 0; juste avant l'accolade fermante de la fonction main

Mes fonctions s'appellent TOUJOURS FcXxxYyyy(...).

Je ne suis personnellement pas vraiment partisan de la notation hongroise
Cela ne rend pas le code vraiment plus facile à lire (au contraire, cela nous oblige à utiliser des identifiants plus complexes) sans réellement apporter de valeur ajoutée réelle

En plus, quitte à utiliser ce genre de convention, il faudrait au minimum la suivre partout, et non seulement pour les fonctions

Les meilleur conventions de nommage sont celles qui sont respectées aussi bien pour définir le nom d'une variable que celui d'une fonction ou encore celui d'un type personnalisé.

Si tu respecte une convention de nommage particulière pour les fonctions, une autre pour les types personnalisés et une troisième pour les noms de variables, il arrivera fatalement un moment où tu t’emmêleras les pinceaux et où tu voudras utiliser une des conventions pour une des choses pour lesquelles tu avais décidé d'en utiliser une autre.

Le résultat sera qu'au final, il n'y aura plus de convention du tout, car on trouveras des noms respectant parfois une convention, parfois l'autre, et il deviendra excessivement difficile de s'y retrouver

Je relirai tous les soirs avant de me coucher cet ensemble de recommandations.
Merci à tous.

voilà une excellente résolution

[senvedgi]

Bon matin,
J'utilise la notation hongroise parce que assez explicite:FcEnrTblFh.
Fc=fonction.
Enr=enregistrement.
Tbl=tableau.
Fh=fichier.
Si on écrit enregistrementduntableaudansunfichier c'est long à lire,à écrire.
A la rigueur EnregistrementdunTableaudansunFichier permettrait de séparer les parties importantes de la notation puisqu'on ne peut pas utiliser d'espace
et donc que je simplifie en FcEnrTblFh:cqfd.
Toujours une majuscule DANS les fonctions:on va plus vite pour identifier le coupable et son lieu de modif.
Hors fonction se serai enrTblFh.
Bien noter que mes fonctions sont testées à part ou en groupe si dépendantes
puis incorporées dans une grande fonction ou un int main général.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
FcAaBb(..)//on construit
{;}
int main()//on teste
{}
----------
FcCcDd(...)//on construit sur un autre écran...
int main()//on teste idem
{}
---------
FcAaBb(...)
FcCcDd(...)
 
int main()
{
//diverses instructions
string ab(..);
//diverses instructions
string cd(...);
}
----------

Voila ma technique de travail.
Concernant le bois vert c'était!
Cordialement.
Je change le titre car maintenant c'est bien écrire du code

[ternel]

C'est sûr que File f = File_FctOpenSavegameStr("save1.sav");est tellement plus clair que File f = openSavegame("save1.sav");Et quand on lit int i = FctAddIntInt(2,3); on comprend mieux que dans int i = add(2, 3); que 2 et 3 sont des entiers.

et qui plus est quand classB hérite de classA, il est trivial de redéfinir

Code :

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

classA[] classA.MtdMultiCloneTblClassAInt(int n);

en

Code :

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

classB[] classB.MtdMultiCloneTblClassBInt(int n);

que

Code :

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

classA[] classA.multiClone(int n);

D'ailleurs, cette notation est si évidente que c'est pour compliquer la tache de tout le monde que le standard ne l'a pas utilisé.

std::string.MtdSubStringIterInt(…) c'est plus simple que std::string.substr(…);

[koala01]

Bon matin,
J'utilise la notation hongroise parce que assez explicite:FcEnrTblFh.
Fc=fonction.

Fc= ... Fraction

Enr=enregistrement.

Enr= ... enervé

Tbl=tableau.

Tbl = ... tubulaire

Fh=fichier.

Fh = ... FaitcHier

Oui, c'est exactement la réaction que tu auras lorsque tu devras relire ton code et que tu tomberas sur ce nom de fonction après avoir eu le temps d'oublier la signification de tes abréviations: "fait chier!!!"

Comme je te l'ai fait remarquer, tes noms doivent être un explicites.

Une abréviation n'est jamais explicite car, dans trois mois, tu auras oublié ce qu'elle signifie

Si on écrit enregistrementduntableaudansunfichier c'est long à lire,à écrire.
A la rigueur EnregistrementdunTableaudansunFichier permettrait de séparer les parties importantes de la notation puisqu'on ne peut pas utiliser d'espace

Je vais être cru, mais...

Le fait que ce soit une fonction, on s'en tape: on le remarque sans aucun problème.

Le fait que l'on enregistre un tableau, on s'en tape aussi : le prototype de la fonction nous l'indique parfaitement.

Il reste donc deux information importantes à donner sur la fonction:

1. le fait que l'on enregistre quelque chose
2. Le fait que la chaine de caractères que l'on fournit est le nom d'un fichier.

Le nom de la fonction pourrait donc être proche de enregistrementFichier, ou, mieux encore saveToFile, si tu aimes les noms courts ( l'anglais ou le franglais est, d'une certaine manière la langue "naturelle" des programmeurs )

De plus, C++ autorise ce que l'on appelle la "surcharge de fonctions": le fait qu'une fonction peut parfaitement ne varier que par la nature ou le nombre de paramètres

et donc que je simplifie en FcEnrTblFh:cqfd.

Commences par simplifier en ne fournissant que les informations indispensables avant d'utiliser des abréviations: cqfd

Plutôt que d'avoir cinq noms de fonctions d'enregistrement dans un fichier différents (un pour l'enregistrement d'un tableau, un autre pour l'enregistrement d'une personne, un troisième pour l'enregistrement d'un vélo, etc..), qui impliqueraient que tu doive retenir les cinq noms afin de pouvoir choisir le nom de fonction qui correspond à ton besoin, tu peux parfaitement envisager de créer autant de fonctions qui portent le même nom et dont seul le type d'un (ou de plusieurs) paramètre(s) ou leur nombre changera.

Ainsi, tu pourrais avoir

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//fonction qui enregistre une personne dans le fichier
void saveToFile(Person const &, std::string const & filename)
// fonction qui enregistre un entier dans un fichier
void saveToFile(int , std::string const & filename)
// fonction qui enregistre une chaine de caractères dans un fichier
void saveToFile(std::string const & toSave, std::string const & filename)
// fonction qui enregistre un vélo dans un fichier
void saveToFile(Bicycle const & , std::string const & filename)
//fonction qui enregistre un tableau de vélo dans un fichier
void saveToFile(std::vector<Bicycle> const & , std::string const & filename)
/*...*/

et tu saurais donc que, si tu dois enregistrer quelque chose dans un fichier, il "suffit" d'appeler "saveToFile" et de passer:

• en premier paramètre: ce que tu veux enregistrer
• en deuxième paramètre: le nom du fichier

Si tu rajoutes un troll ou un orc à la liste, tu peux partir du principe que tu peux l'enregistrer de la même manière : de toutes façons, le compilateur t'engueulera s'il ne trouve pas le bon prototype de fonction avec un message d'erreur proche de "impossible de trouver saveToFile(Troll const &, std::string const &)"

D'ailleurs, à bien y réfléchir, cela impliquerait que chaque fonction va ouvrir son propre fichier et le refermer à chaque fois.

Sauf peut etre pour la fonction qui enregistre un tableau de vélos, qui, je l'espère pour toi, appellera la fonction d'enregistrement de vélos...Sauf que cela signifie que le fichier sera ouvert et fermé un nombre de fois correspondant au nombre de vélos à enregistrer

On peut, clairement, trouver plus efficace que d'ouvrir et de fermer le fichier à chaque fois !!!

Si on passe directement le fichier en paramètre, on peut encore simplifier le nom et avoir des prototypes proches de:

Code :

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

1
2
3
4
5
void save(Person const & , std::ofstream &)
void save(Bicycle const &, std::ofstream &)
void save(int, std::ofstream &)
void save(Troll const &, std::ofstram &)
...

L'avantage

C'est que l'enregistrement peut se faire aussi, pourquoi pas, au travers d'une connexion à une base de données...

On garde le même nom, il n'y a qu'un paramètre qui change

Code :

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

1
2
3
4
5
void save(Person const & , BddConnection &)
void save(Bicycle const &, BddConnection  &)
void save(int, BddConnection  &)
void save(Troll const &, BddConnection  &)
...

Et si l'on veut enregistrer nos objets dans "quelque chose" auquel je ne pense pas forcément, il suffira de changer le type du paramètre de "destination" et d'implémenter la fonction


Que penses tu de MA simplification, en terme de lecture du code

Toujours une majuscule DANS les fonctions:on va plus vite pour identifier le coupable et son lieu de modif.
Hors fonction se serai enrTblFh.

Avec ma convention, ne crois tu pas que l'on sache aussi exactement identifier le coupable en cas de problème

De plus, cela permettra, une fois que tu auras apprivoisé le langage, des choses plutôt sympa, comme l'utilisation des templates, sous une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
template <typename Destination>
void saveAll(std::vector<Person> const & persons, 
             std::vector<Bicycle> const & bicycles,
             std::vector<Troll> const & trolls, 
             std::vector<Orcs> const & orcs,
             Destination & destination)
{
    save(persons, destination);
    save(bicycles, destination);
    save(trolls, destination);
    save(orcs, destination);
}

Avec ce code, tu n'as qu'à fournir la destination que tu souhaites, et tu est sur que c'est la bonne version de la fonction (celle qui attends les paramètres du bon type) qui sera appelée, et tu n'auras même plus à t'embêter à copier cinq fois une logique sommes toutes identiques pour te permettre de sauvegarder tes éléments dans cinq types de destination différents

Tout ce qu'il te faudra, c'est que la fonction save existe pour les choses à sauvegarder et pour la destination envisagée

Ceci dit, tu pourrais d'ailleurs encore faire mieux en décidant d'uniformiser l'interface de tes différentes "destinations" possibles!!!

Tu pourrais alors en arriver à n'écrire qu'une fois le code de save pour chaque type qu'il faut enregistrer de manière indépendante de la destination.

Tant que tu fourniras un type pour la destination qui respecte l'interface que tu prévois que la destination aie, tu pourras, sans copier une seule ligne de code, enregistrer tes éléments dans n'importe quel type de destination que tu pourrais envisager.

Cette manière de travailler te fera gagner énormément de temps car, une fois que tu auras validé ta logique et validé le fait que ta destination est bel et bien capable d'enregistrer "quelque chose" et que tu es bel et bien capable de le récupérer "plus tard", tu pourras considérer que, si problème il y a, c'est qu'il est ailleurs

Mais bon, ca, c'est surement pour "plus tard", quand tu te seras correctement approprié le langage

Une telle manière de travailler est totalement impossible avec la notation hongroise, pour la simple et bonne raison que tu 25 noms de fonction différents s'il ne s'agissait que de permettre l'enregistrement de cinq types de données particuliers dans cinq types de destination particuliers

La simplification d'écriture pour l'instant présent n'est jamais une bonne chose, essentiellement parce que les problèmes apparaissent toujours "plus tard"

Une bonne simplification doit être "à l'épreuve du temps" de manière à ce que tu puisse, même dans cinq ans, avec de nouvelles habitudes et de nouvelles conceptions apportées par ton expérience, te retrouver dans le code presque aussi facilement que si tu l'avais écrit la veille

Bien noter que mes fonctions sont testées à part ou en groupe si dépendantes
puis incorporées dans une grande fonction ou un int main général.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
FcAaBb(..)//on construit
{;}
int main()//on teste
{}
----------
FcCcDd(...)//on construit sur un autre écran...
int main()//on teste idem
{}
---------
FcAaBb(...)
FcCcDd(...)
 
int main()
{
//diverses instructions
string ab(..);
//diverses instructions
string cd(...);
}
----------

Voila ma technique de travail.

L'habitude qui consiste à tester à fond les différentes fonctions de manière indépendante est une excellente chose, que je t'encourage à garder, et que je ne remet absolument pas en cause.

Ce que je remet en cause, c'est ta politique de nommage au vu des possibilités qu'elle te ferme et au vu des problèmes que mon expérience m'assure que tu ne manqueras pas d'avoir avec cette politique .

S'il y a une seule certitude à avoir en informatique, c'est que l'on ne peut etre sur de rien : avec le temps, les besoins évoluent systématiquement et l'on se retrouve très régulièrement avec des besoins que l'on aurait volontiers qualifiés de "complètement inutiles", de "décidément improbables" ou de "pure science fiction".

Quand tu te retrouves avec de tels besoins nouveaux, tu te retrouve dans une situation dans laquelle il faut aller "fouiller tes archives" de manière à faire évoluer du code que tu pensais pourtant "définitif" au moment où tu l'as validé.

Le problème, c'est que les nouveaux besoins peuvent apparaitre tout aussi bien deux jours après avoir écrit ton code "définitif" que... quelques mois cinq ans plus tard, bref, après t'avoir laisser bien plus que le temps d'oublier à quoi correspond une abréviation dans le nom d'une fonction

Qu'à la limite, tu utilises une abréviation dans le nom d'une variable dont la portée est très limitée (par exemple : cpt pour un compteur), cela peut encore passer, mais, plus tu monte dans des portées importantes, plus tu te dois d'être clair et précis dans tes règles de nommage.

Or, par définition, une fonction peut etre appelée depuis "n'importe où" dans ton programme. On fait difficilement une portée plus grande dans laquelle on peut vouloir l'utiliser

C'est sûr que File f = File_FctOpenSavegameStr("save1.sav");est tellement plus clair que File f = openSavegame("save1.sav");Et quand on lit int i = FctAddIntInt(2,3); on comprend mieux que dans int i = add(2, 3); que 2 et 3 sont des entiers.

et qui plus est quand classB hérite de classA, il est trivial de redéfinir

Code :

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

classA[] classA.MtdMultiCloneTblClassAInt(int n);

en

Code :

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

classB[] classB.MtdMultiCloneTblClassBInt(int n);

que

Code :

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

classA[] classA.multiClone(int n);

D'ailleurs, cette notation est si évidente que c'est pour compliquer la tache de tout le monde que le standard ne l'a pas utilisé.

std::string.MtdSubStringIterInt(…) c'est plus simple que std::string.substr(…);

Tu me le retires de la bouche... enfin, du clavier, dis donc

[ternel]

koala01, tu es un génie.

Non seulement, tout se conçoit tellement bien pour toi que tu trouve un torrent de mots pour le dire, mais en plus, tu veux sauvegarder un troll et un orc.

rôliste inside!!!

[koala01]

koala01, tu es un génie.

Fallait pas l'écrire, maintenant, tout le monde va le savoir

Non seulement, tout se conçoit tellement bien pour toi que tu trouve un torrent de mots pour le dire,

Et encore, je me retiens

Fut un temps, les modérateurs s'amusaient à épeingler dans un forum spécial les romans que j'écrivais

Par chance, ca leur est passé

[senvedgi]

Toujours pleins de bons sens ces propos d'écrivain spécialisé malheureusement je fais avec mon très maigre bagage, mais
bagage que je comprends et qui marche.

[koala01]

On a tous commencé avec un "maigre bagage"...

Ce n'est pas une raison pour le brandir comme une défense à la moindre remarque qui se veut constructive et justifiée

Au contraire, tu devrais profiter de ce genre de remarque pour te remettre en question le plus vite possible car les mauvaises habitudes sont celles qui sont les plus difficiles à perdre (et c'est un fumeur qui te le dit ).

Si une remarque te parait fondée et "pleine de bon sens", qu'elle soit "bazardée" en deux mots ou abordée à la manière d'un roman, c'est à toi de voir ce que tu en fais, mais la réaction la plus saine est sans doute de la prendre en considération, non

Si tu veux un jour pouvoir te considérer comme un "bon développeur" (ou seulement comme un développeur "pas trop mauvais" ), que ce soit à titre professionnel ou privé, il faut absolument te remettre systématiquement en question, surtout lorsque l'on te donne des raisons de le faire, car, autrement, tu continueras à refaire les même erreurs et tu n'évolueras pas.

C++ compte parmi les langages les plus complexes que je connaisse, bien que l'on puisse en apprendre la syntaxe en quelques heures à peine, pour une série de questions qui déborderaient vraiment trop de la discussion actuelle.

Mais sa complexité implique qu'il faut vraiment profiter de toutes les occasions qui nous sont données d'écrire un code intelligible et facilement lisible : il est déjà suffisamment difficile comme cela de suivre certains code sans que l'on doive, en plus, perdre du temps à essayer de comprendre ce que l'auteur du code avait en tête au moment de choisir un nom de variable, de type personnalisé ou de fonction

[senvedgi]

Pour moi la POO si j'en comprends le sens général (une maison c'est des murs, des fenêtres, des portes donc dérivants les uns des autres OU en puissance dans chaque mot) je ne sais pas l'appliquer concrètement.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
template <typename Destination>
void saveAll(std::vector<Person> const & persons, 
             std::vector<Bicycle> const & bicycles,
             std::vector<Troll> const & trolls, 
             std::vector<Orcs> const & orcs,
             Destination & destination)
{
    save(persons, destination);
    save(bicycles, destination);
    save(trolls, destination);
    save(orcs, destination);
}

pfuitt!!!:pour moi concis,élégant.
Sur ce site il faut évidemment prêcher la bonne parole:

Dans un autre ordre d'idée:

Code :

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

1
2
int a;
int a=0;

c'est bien écrit?
Et aussi : int b=0; est une affectation avec un seul signe =.

if (qqchose == b) est aussi une affectation mais avec 2 signes ==.
Pourquoi même mot affectation avec 2 écritures différentes?
Cordialement.

[koala01]

Pour moi la POO si j'en comprends le sens général (une maison c'est des murs, des fenêtres, des portes donc dérivants les uns des autres OU en puissance dans chaque mot) je ne sais pas l'appliquer concrètement.

En fait, la POO, consiste à considérer les types que tu crées comme des objets qui doivent être capable de fournir un certain nombre de services.

Tu vas d'avantage t'intéresser aux services rendus (ou aux comportements que ces services impliquent) qu'aux données qui leur permettent de rendre ces services (du moins, dans un premier temps, car tu devras quand meme trouver une manière de représenter les données qui permettent aux objets de rendre les services que tu en attends )

La POO est, essentiellement, caractérisée par ce que l'on appelle la substituabilité (reporte toi à l'entrée concernant le principe de substitution de liskov dans la FAQ

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
template <typename Destination>
void saveAll(std::vector<Person> const & persons, 
             std::vector<Bicycle> const & bicycles,
             std::vector<Troll> const & trolls, 
             std::vector<Orcs> const & orcs,
             Destination & destination)
{
    save(persons, destination);
    save(bicycles, destination);
    save(trolls, destination);
    save(orcs, destination);
}

pfuitt!!!:pour moi concis,élégant.

Là, on est dans un paradime nommé "générique"...
C'est un paradigme par lequel on va se dire que l'on ne sait peut etre pas quelle données on va manipuler, mais que l'on sait par contre exactement comment on va les manipuler.

Dans l'exemple que tu cites, je me base sur le principe que je ne sais pas où je vais sauvegarder mes personnes, mes vélos, mes trolls et mes orcs.

Ce pourrait tout aussi bien être dans un fichier que dans une base de données ou dans tout autre chose. Par contre, je sais comment je vais sauvegarder ces données dans ces différentes destinations

Un autre exemple nous est donné par les différents type de collections fournies par le langage car, quelle que soit la donnée que tu devras placer dans un tableau, une pile, une file, une liste, ou un tableau associatif, la manière de les gérer pour un de ces types de collection restera identique

Mais il est vrai que cela permet d'être "élégant et concis", et, surtout, cela nous évite bien des fois d'avoir à dupliquer du code
Sur ce site il faut évidemment prêcher la bonne parole:
----

Dans un autre ordre d'idée:
int a;

Cela, c'est une déclaration de variable

int a=0;

Ceci, c'est une définition de variable (tu déclares une variable et tu lui assignes une valeur)

c'est bien écrit?

oui

Et aussi:
int b=0; est une affectation avec un seul signe<=>.

if (qqchose == b est aussi une affectation mais avec 2 signes <==>.

un signe égal, c'est bel et bien une affectation, mais deux, c'est une comparaison d'égalité

Le if signifie d'ailleurs "si", et évalue une expression booléenne (dont le résultat final ne peut etre que "oui" (true) ou "non" (false) )

Pourquoi même mot affectation avec 2 écritures différentes?
Cordialement.

Parce que la deuxième écriture n'est pas une affectation

[gbdivers]

HS...

Je chipote, pour voir si je me trompe pas dans mes définitions.

Dans un autre ordre d'idée:
int a;

Cela, c'est une déclaration de variable

int a=0;

Ceci, c'est une définition de variable (tu déclares une variable et tu lui assignes une valeur)

Code :

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

1
2
3
extern int a; // déclaration
int a; // déclaration et définition
int a = 0; // déclaration, définition et initialisation

Les build-in types sont par défaut déclaré et définit en même temps, il faut utiliser extern pour ne faire qu'une déclaration

Mais ce n'est pas le cas pour les classes par exemple :

Code :

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

1
2
class A; // déclaration
class A {}; // déclaration et définition

J'ai tort ou c'est koala01 qui a fait un raccourci ?

[ternel]

Non, non, en effet, avec int a; a est déclaré et possède une valeur, non explicité.
Pour tout type non primitif, il y a un appel au constructeur par défaut. Pour les primitifs, l'équivalent est "laisser la valeur précédemment contenue dans le bloc mémoire" autrement dit "pas d'instructions"