bien écrire en c/c++

Version imprimable

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

Code:

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.:oops:

27/11/2012, 14h18
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é.
27/11/2012, 14h30
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".:aie:
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.
27/11/2012, 16h32
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.
27/11/2012, 17h09
koala01
Salut,

Citation:

Envoyé par senvedgi

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é ;)
Citation:

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:

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

ne respecte aucune de ces règles de base ;)

Il devrait ressembler à
Code:

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é ;))
Citation:

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:

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 ;)
Citation:

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

Dans la vraie vie :question:

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

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 :furieux: 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 :aie:

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:

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" ;)
27/11/2012, 17h22
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.
27/11/2012, 17h48
koala01

Citation:

Envoyé par leternel

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 :D

Je ne fais qu'essayer d'appliquer les principes que j'énonce dans les deux première lignes de ma signature ;)
27/11/2012, 21h25
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.:ccool:
27/11/2012, 22h52
koala01

Citation:

Envoyé par senvedgi

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 :question: :D

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" (:D) sont vraiment justifiés ;)

Citation:

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 ;)

Citation:

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 ;)

Citation:

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 8O:furax:

Citation:

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 ;)

Citation:

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

voilà une excellente résolution ;)

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:

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:lol:!
Cordialement.
Je change le titre car maintenant c'est bien écrire du code

28/11/2012, 11h41
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:

classA[] classA.MtdMultiCloneTblClassAInt(int n);

en

Code:

classB[] classB.MtdMultiCloneTblClassBInt(int n);

que

Code:

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(…);

Citation:

Envoyé par senvedgi

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

Fc= ... Fraction :question:

Citation:

Enr=enregistrement.

Enr= ... enervé :question:

Citation:

Tbl=tableau.

Tbl = ... tubulaire :question:

Citation:

Fh=fichier.

Fh = ... FaitcHier :question: :aie:

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 ;)

Citation:

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:

le fait que l'on enregistre quelque chose
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 ;)

Citation:

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 :D

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:

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 :aie:

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:

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 :question:

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:

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 :question:

Citation:

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 :question:

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:

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 ;)
Citation:
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:

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 ;)

Citation:

Envoyé par leternel

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:

classA[] classA.MtdMultiCloneTblClassAInt(int n);

en

Code:

classB[] classB.MtdMultiCloneTblClassBInt(int n);

que

Code:

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 :cry: ;)

28/11/2012, 14h59
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!!!
28/11/2012, 15h22
koala01

Citation:

Envoyé par leternel

koala01, tu es un génie.

:whistle:

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

Citation:

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 :D

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é :D
28/11/2012, 17h39
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.
:pc::cry:
29/11/2012, 01h33
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 :question:

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 ;)

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:

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::hola:

Dans un autre ordre d'idée:
Code:

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.

Citation:

Envoyé par 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.

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 ;)
Citation:
Citation:
Code:

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::hola:
----

Citation:

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

Cela, c'est une déclaration de variable

Citation:

int a=0;

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

Citation:

c'est bien écrit?

oui

Citation:

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) ;) )

Citation:

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

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

29/11/2012, 09h51
gbdivers
HS...

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

Citation:

Envoyé par koala01

Citation:

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

Cela, c'est une déclaration de variable

Citation:

int a=0;

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

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:

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 ?
29/11/2012, 10h00
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"
29/11/2012, 10h01
Bousk

Je pense qu'il s'agit d'un raccourci, voire d'un abus de langage. Mais au final on se comprend tous. :P

Pour moi, int a; est une déclaration de variable, alors que class A; est une déclaration de type. Mais déclarer un type ne suffit pas à l'utiliser, il faut aussi qu'il soit défini.
extern étant à part puisqu'il s'agit uniquement d'indiquer que oui, cette variable existe, d'en donner la nature, mais de ne pas se soucier d'où elle vient.

Après, le fait est qu'en C++ toute variable déclarée est initialisée (je préfère ce terme à "définie", on déclare et initialise une variable, on déclare et définit un type) immédiatement. Avec des valeurs aléatoires pour les types par défaut, le constructeur par défaut pour class et struct.
29/11/2012, 10h15
gbdivers

J'ai encore foiré avec mes exemples...

Le but était surtout de dire que déclaration, définition et initialisation sont 3 concepts différents, même si parfois (souvent), on fait plusieurs choses en même temps :
* déclaration : déclarer un nouveau "mot" au compilateur, pour qu'il sache qu'il existe ensuite
* définition : dire à quoi correspond un "mot" (ie le contenu de son type)
* initialisation : donner une valeur à un "mot"

Faudrait que je retrouve les définitions exactes dans la norme (si c'est bien dans la norme)... (ou attendre que Flob90, qui a appris par coeur la norme, passe dans le coin)
29/11/2012, 10h17
ternel

J'apprécie l'autre choix de vocabulaire, je trouve qu'il colle mieux avec la vie courante.

Lorsqu'on déclare quelque chose, on ne fait que dire "je l'ai", exactement comme lorsqu'on déclare ses revenus, on n'envoie pas un relevé de compte…

De même une définition donne du sens au défini. C'est le principe même d'un dictionnaire.
On a alors la possibilité de la définition par défaut, c'est à dire "comme tu t'y attends", avec le fait que tu ne t'attends à rien de précis que je dis "un entier".

Edit: zut, doublé par gbdivers
29/11/2012, 11h03
senvedgi

Tout çà est bien enregistré.
Et on ne devrait plus avoir de mauvais écrivains.
Hug!:salut::love:
30/11/2012, 01h48
JolyLoic
Une autre différence importante entre déclaration et définition est l'unicité. Tu ne peux définir une variable qu'une seule fois dans un programme, tu ne peux définir une fonction non inline qu'une seule fois dans un programme, tu ne peux définir un type qu'une seule fois dans une unité de compilation (mais dans le programme, chaque définition doit être la même)... (c'est ce qu'on nomme la One definition rule). Tu peux déclarer toutes ces choses autant de fois que tu veux.
Code:

1 2 3 4 5 6 extern int a; // déclaration extern int a; // déclaration extern int a; // déclaration extern int a; // déclaration int a; // Définition int a; // Erreur : Redéfinition
La définition dans la norme de déclaration/définition est dans le 3.1, mais ce n'est pas très agréable à lire, et ne décrit pas la philosophie qu'il y a derrière :

Citation:

A declaration (Clause 7) may introduce one or more names into a translation unit or redeclare names introduced by previous declarations. If so, the declaration specifies the interpretation and attributes of these names. A declaration may also have effects including:
— a static assertion (Clause 7),
— controlling template instantiation (14.7.2),
— use of attributes (Clause 7), and
— nothing (in the case of an empty-declaration).
2 A declaration is a definition unless it declares a function without specifying the function’s body (8.4), it contains the extern specifier (7.1.1) or a linkage-specification25 (7.5) and neither an initializer nor a functionbody, it declares a static data member in a class definition (9.2, 9.4), it is a class name declaration (9.1), it is an opaque-enum-declaration (7.2), it is a template-parameter (14.1), it is a parameter-declaration (8.3.5) in a function declarator that is not the declarator of a function-definition, or it is a typedef declaration (7.1.3), an alias-declaration (7.1.3), a using-declaration (7.3.3), a static_assert-declaration (Clause 7), an attributedeclaration (Clause 7), an empty-declaration (Clause 7), or a using-directive (7.3.4).

Et, puisqu'on est en mode chipotage :
Code:

1 2 int i; int j = i;
Formellement, l'effet n'est pas de mettre une valeur aléatoire dans j, mais ce code est un comportement indéfini, le compilateur est en droit lors de l'exécution de rédiger en vers et en espéranto une lettre d'injure et de la mailer au patron/professeur/autre du codeur responsable, ou toute autre action qu'il jugera utile ;)
En pratique, sur certaines architecture, on pourra avoir plantage si la "valeur" initiale ne correspond pas à une valeur valide pour le type concerné.