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