#76 Le 04/11/2007, à 12:55
- $Gaël$
Re : Questions sur la P.O.O. (C++ et JAVA)
baaaaaaaaaah ! J'ai un prof qui est fan de la notation hongroise 
Je comprends jamais rien dans ses programmes !! Cela dit se donner des conventions de nommage peut-être intéressant, notamment avec des objets graphiques (ie. btnOK pour bouton OK). C'est aussi ce qui permet de faire un code propre pour reprendre ce qu'a dit Farfadet Spatial !!;)
@Le Farfadet Spatial :
Le problème de l'impératif, par comparaison à l'orienté objet, au fonctionnel ou à la programmation logique, c'est que les langages sont apparus sans réelle théorisation du paradigme --- à peine la notion de calculabilité de Turing. Du coup, on voit apparaitre les inconvénients d'une absence de formalisme, dans une activité (la programmation) qui au contraire appel un formalisme fort : tout est laissé à la charge du programmeur, qui peu aussi bien produire un code bancal qu'un code propre et robuste. Mais je m'égare...
Je dois avouer que la première moitié de ton paragraphe ne me parle pas trop non plus 
On sent le mathématicien qui veut produire des programmes au fonctionnement infaillible sans bug 
Ils sont pas en contrat avec la NASA au LEGOS?? 
@Aganim07:
Si ca peut t'aider pour comprendre l'utilité, voici un exemple (bidon ^^) de création dynamique avec de l'héritage:
Dans un programme tu sais qu'à un moment tu devras créer un objet porte, seulement le type de porte peut changer, ca peut être une porte classique comme une porte de saloon.
Tu as créé une classe (virtuelle) Porte (toutes les portes ne s'ouvrent pas de la même façon, chaque classe dérivée implémentera donc son ouverture de porte)
Tu as créé 2 classes dérivées de Porte, nommées PorteNormal et PorteSaloon
En premier tu déclares un pointeur de Porte
Ensuite dans ton programme selon le choix de l'utilisateur, tu créeras de façon dynamique une PorteNormale ou une PorteSaloon.
Porte* porte;
if(...) porte = new PorteSaloon(...)
else porte = new PorteNormale(...)Bon c'est pourri mais c'est pour l'idée ^^
Dernière modification par $Gaël$ (Le 04/11/2007, à 12:56)
Ubuntu is an ancient african word meaning : "I can't configure Debian".
Hors ligne
#77 Le 04/11/2007, à 15:33
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Je me tape tous les chapitres sur les constructeurs, destructeurs, surcharges de constructeurs, constructeurs de copie, membres et méthodes statiques etc...
J'ai la tête qui va exploser. Le pire c'est que même si je comprends avec difficulté et que j'ai l'impression que dans une heure j'aurai tout oublé, bah le pire c'est que je comprend tout ce que je lis. Depuis 24h g un gros déclic et je peux plus m'arrêter car je prends conscience des lacunes que j'ai 
Hors ligne
#78 Le 04/11/2007, à 16:10
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Ptite question comme ça :
#include<cstdio> et #include <cstdlib> sont remplacés par #include<string> ??
Je veux dire : Quand on appele string on a aussi besoin d'appeler cstdio et cstdlib ou pas ?
Hors ligne
#79 Le 04/11/2007, à 16:14
- $Gaël$
Re : Questions sur la P.O.O. (C++ et JAVA)
Non
cstdio, cstlib => biblio C
string => biblio C++
Ubuntu is an ancient african word meaning : "I can't configure Debian".
Hors ligne
#80 Le 04/11/2007, à 16:19
- Le Farfadet Spatial
Re : Questions sur la P.O.O. (C++ et JAVA)
Salut à tous !
Merci, $Gaël$, tu m'as bien fait rire !
baaaaaaaaaah ! J'ai un prof qui est fan de la notation hongroise
À une époque, j'étais un adepte de la notation hongroise. J'en suis revenu, d'abord parce qu'avec les modèles, ça perd pas mal de sa pertinence, ensuite parce que, peu à peu, les noms deviennent longs et abscons, en un mot illisibles...
Décidément, trouver des noms adaptés est quelque chose de difficile, plus proche d'un art que d'une science...
Je dois avouer que la première moitié de ton paragraphe ne me parle pas trop non plus
Pour mon grand malheur, je suis un matheux perdu au milieu de physiciens --- y'a même des chimistes, au secours ! Pire : le code sur lequel je travaille a été créé par des gens qui ont appris la programmation sur le tas, en Fortran, qui ont ensuite traduis leur code en C, pour finalement le compiler avec un compilateur C++ : j'vous dis pas, je suis régulièrement à deux doigts de la crise cardiaque...
En plus, le choc culturel est assez fort : pour ma part, avant de coder, je fais une étude algorithmique, avec analyse de la complexité en temps et en espace (habitude qu'ils n'ont pas du tout). Sans oublier que je fais du C++ en utilisant ses fonctionnalités avancées (qu'ils ne connaissent guère), du coup je dois être le seul dans l'équipe à comprendre mon code ! Le plus étonnant, c'est que ce modèle fonctionne plutôt bien...
Quand à produire du code code infaillible sans bogues, si j'avais une solution pour y parvenir, je serais sans doute moins malheureux en informatique ! Cela dit, oui, je suis un théoricien et la production de code correct a fait partie des sujets que j'ai abordés. Forcément, ça laisse des traces...
Sinon, je l'ai trouvé pas mal ton exemple avec les portes, $Gaël$ !
D'autre part :
Depuis 24h g un gros déclic et je peux plus m'arrêter car je prends conscience des lacunes que j'ai yikes
Je ne veux pas avoir l'air, mais c'est également ce que disent les joueurs compulsifs et les accrocs aux substances psychotropes... De là à dire que le geek est une sorte de drogué, il n'y a qu'un pas que je franchis allégrement.
Sur ce, je vais me replonger dans un traité de topologie dans les espaces non convexes, je suis en manque...
À bientôt.
Le Farfadet Spatial,
qui se sent un peu comme
le « h » de « Hawaï » sur
ce coup...
Dernière modification par Le Farfadet Spatial (Le 04/11/2007, à 16:22)
Hors ligne
#81 Le 04/11/2007, à 16:27
- Le Farfadet Spatial
Re : Questions sur la P.O.O. (C++ et JAVA)
Re-salut à tous !
Ptite question comme ça :
#include<cstdio> et #include <cstdlib> sont remplacés par #include<string> ??
Je veux dire : Quand on appele string on a aussi besoin d'appeler cstdio et cstdlib ou pas ?
Pour ajouter à ce qu'a écrit $Gaël$, la réponse est : « ou pas. » Par contre, tu peux ajouter :
include <iostream>Ça ne mange pas de pain.
En gros, tous les en-têtes de la bibliothèque standard qui commence par la lettre « c » sont des encapsulations des bibliothèques standards du C, mais insérées dans l'espace de nommage « std. » Dans la mesure du possible, préfère les bibliothèques C++.
À bientôt.
Le Farfadet Spatial
Dernière modification par Le Farfadet Spatial (Le 04/11/2007, à 16:27)
Hors ligne
#82 Le 04/11/2007, à 16:47
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Ok merci. Ouéé je suis un geekounet développeur compulsif. Et alors ??
Hors ligne
#83 Le 04/11/2007, à 16:55
- $Gaël$
Re : Questions sur la P.O.O. (C++ et JAVA)
Merci, $Gaël$, tu m'as bien fait rire !
Je te retourne le compliment ! et te souhaite bon courage avec tes collègues
peu à peu, les noms deviennent longs et abscons, en un mot illisibles...
Complètement d'accord ! Pour moi un entier c'est un int et pas un ent et encore moins un eMachinTruc !!
avant de coder, je fais une étude algorithmique, avec analyse de la complexité en temps et en espace
J'ai cru entendre que ce domaine avait de l'avenir et que des recherches étaient à l'étude pour généraliser ce genre de travail dans la conception de logiciel! Je dois bien avouer que je ne suis pas forcément partisan (moi et les math... ^^ )
Sinon, je l'ai trouvé pas mal ton exemple avec les portes, $Gaël$ !
Si vous voulez j'en ai un dans le même genre pour les classes abstraites avec des animaux, des cries et des chiens et des aboiement !!
Hawai sans H, c'est Awai et çà je sais pas ou c'est
Ubuntu is an ancient african word meaning : "I can't configure Debian".
Hors ligne
#84 Le 04/11/2007, à 17:03
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Autour de mes problèmes, tout le monde se retrouve visiblement.
Passez boire un coup à l'occasion, on parlera de pointeurs en C++ 
Dernière modification par aganim07 (Le 04/11/2007, à 17:03)
Hors ligne
#85 Le 04/11/2007, à 17:16
- Le Farfadet Spatial
Re : Questions sur la P.O.O. (C++ et JAVA)
Re-re-salut à tous !
Le Farfadet Spatial a écrit :peu à peu, les noms deviennent longs et abscons, en un mot illisibles...
Complètement d'accord ! Pour moi un entier c'est un int et pas un ent et encore moins un eMachinTruc !!
En fait, elle a l'effet inverse de ce pour quoi elle a été inventée : elle est censée rendre les codes plus lisibles, elle les moins compréhensibles.
La notation hongroise a un sens en C, d'abord parce qu'alors elle produit des noms moins complexes que ce qu'elle donne en C++, ensuite parce que, C étant faiblement typé, elle aide le programmeur à s'assurer qu'il ne fait pas d'erreur de type. Le C++ étant plus fortement typé que le C, ça n'a plus d'utilité.
D'ailleurs, puisque l'on parle de bonne manière de programmer en C++ et que je viens d'aborder le typage, j'en profite pour un autre conseil : C++ n'est pas un langage fortement typé, à cause de la conversion de type C (même s'il est plus fortement typé). Vous savez, ce genre d'horreur :
caractere = (char) chaine;Source de bogues étranges, surtout quand on commence à mélanger ça avec des pointeurs. Or, C++ propose quatre mécanismes : le transtypage statique --- statique_cast, le plus utilisé, --- le transtypage dynamique (dynamic_cast), la réinterprétation de données (reinterpret_cast) et enfin la conversion implicite, cette dernière étant celle-ci :
int i = 4;
long j = i; // Ici, conversion impliciteSans oublier const_cast, bien sûr.
Donc, pour bien faire, faites disparaître toutes les conversions de type C d'un programme C++, vous ne vous en porterez que mieux !
Le Farfadet Spatial a écrit :avant de coder, je fais une étude algorithmique, avec analyse de la complexité en temps et en espace
J'ai cru entendre que ce domaine avait de l'avenir et que des recherches étaient à l'étude pour généraliser ce genre de travail dans la conception de logiciel! Je dois bien avouer que je ne suis pas forcément partisan
Tu sais, ces analyses remontent aux années soixante-dix (voir Donald E. Knuth). Il serait temps que tout le monde les adopte, pas seulement les théoriciens...
Si vous voulez j'en ai un dans le même genre pour les classes abstraites avec des animaux, des cries et des chiens et des aboiement
Il faut aussi des caravanes, car lorsque le chien aboie, la caravane passe...
Hawai sans H, c'est Awai et çà je sais pas ou c'est
Surtout qu'en anglais, le « h » a une utilité...
À bientôt.
Le Farfadet Spatial
Dernière modification par Le Farfadet Spatial (Le 04/11/2007, à 17:17)
Hors ligne
#86 Le 05/11/2007, à 14:53
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Bon... j'ai un pb !
Concernant le passage des arguments d'un constructeur, si on met des valeurs par défaut aux arguments dans le constructeur comme ci-dessous, c'est justement pour que si on ne passe pas d'arguments lors de la création d'une instance, bah les arguments soient initialisées avec les valeurs par défaut. Alors pourquoi mon compilateur ne veut pas en entendre parler ?
/*=== Constructeur Option ===*/
Option :: Option(string issue_date = "empty", string maturity_date = "empty", float K = 0., float P = 0., float rendement = 0.) {
cout << "Construction de l'objet" << endl;
this->issue_date = issue_date;
this->maturity_date = maturity_date;
this->K = K;
this->P = P;
this->rendement = rendement;
}Je m'explique, si je mets des valeurs d'argument lors de la création de l'instance, ça compile.
Sinon non... Strange no ??
Dernière modification par aganim07 (Le 05/11/2007, à 14:53)
Hors ligne
#87 Le 05/11/2007, à 15:08
- Link31
Re : Questions sur la P.O.O. (C++ et JAVA)
Je ne vois pas exactement ce que tu veux dire, mais... chez moi ça marche.
#include <string>
#include <iostream>
class Option
{
public:
// Les valeurs par défaut sont autorisées dans la déclaration de la fonction
Option(std::string issue_date = "empty", std::string maturity_date = "empty", float K = 0., float P = 0., float rendement = 0.);
private:
std::string issue_date, maturity_date;
float K, P, rendement;
};
// Il ne faut pas remettre les valeurs par défaut dans la définition de la fonction
Option::Option(std::string issue_date, std::string maturity_date, float K, float P, float rendement)
{
std::cout << "Construction de l'objet" << std::endl;
this->issue_date = issue_date;
this->maturity_date = maturity_date;
this->K = K;
this->P = P;
this->rendement = rendement;
}
int main()
{
Option option;
Option option2("test", "test2");
Option option3("test3", "test4", 2.1, 3.14, 0.0);
return 0;
}Hors ligne
#88 Le 05/11/2007, à 15:11
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Ok j'ai compris ce qui n'allait pas. Je fais systématiquement toutes mes déclarations en outline.
Dans le livre que j'utilise, c'est le contraire.
Du coup j'ai cru qu'il fallait passer les valeurs d'arguments par défaut dans la définition outline de la méthode alors que c seulement dans le prototype de la classe (donc en inline). C'est ta remarque dans ta réponse qui m'a fait prendre conscience de cela...
Bientôt un autre exemple de mini programme. Constates-tu des progrès dans mon code ?
J'espère que oui car j'en lis des documents !!
Encore merci 
Dernière modification par aganim07 (Le 05/11/2007, à 15:12)
Hors ligne
#89 Le 05/11/2007, à 15:17
- Link31
Re : Questions sur la P.O.O. (C++ et JAVA)
Constates-tu des progrès dans mon code ?
Difficile à dire avec seulement 8 lignes de code...
Les std::string, il vaut mieux les passer en référence constante :
Option::Option(const std::string& issue_date, const std::string& maturity_date, float K, float P, float rendement)Ça évite qu'ils soient copiés pour rien. Le gain de performance est assez négligeable, mais autant s'habituer à de bonnes pratiques. Quand tu devras passer une image de 150 Mo en paramètre, tu verras que ça peut être utile (c'est un exemple, ton programme plantera bien avant d'avoir pu faire rentrer 150 Mo dans la pile ).
Dernière modification par Link31 (Le 05/11/2007, à 15:18)
Hors ligne
#90 Le 05/11/2007, à 15:26
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Oui c vrai que 8 lignes de codes
Patience le reste arrive ! Au menu des classes (ouiiiii il y en aura deux !!!) et des constructeurs/destructeurs dignes de ce nom.
Pitetre un héritage aussi mais ça c'est pas certain.
Le C++ c'est trop cool !!! En plus je suis payé pour faire tout cela car je suis en inter-contrat dans ma SSII. Oui aujourd'hui c'est mon premier jour de boulot alors... J'espère quand même que cette période creuse ne durera pas trop !!
Dernière modification par aganim07 (Le 05/11/2007, à 15:26)
Hors ligne
#91 Le 05/11/2007, à 16:43
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Voici mon nouveau programme Bon ça ne compile pas encore...
C'est plus dur que ce que je pensais de faire un héritage de classe.
edit : Ah bah si ça compile... crévindju c'est pas croyable que ça compile ! *_*
main.cpp
// main.cpp
/*=== Header ===*/
#include<iostream>
#include<string>
#include<vector>
#include"classe.h"
using namespace std;
/*=== Fonction main ===*/
int main(int argc, char* argv[]) {
Future* pFuture; // INSTANCE de la classe Future
pFuture = new Future; // Méthode dynamique
pFuture->affiche();
delete pFuture; // Appel manuel du destructeur
pFuture = NULL; // Pointeur inutile positionné sur NULL (le boulet)
Option* pOption;
pOption = new Option;
pOption->affiche();
delete pOption;
pOption = NULL;
system("PAUSE"); //Cette instruction fonctionne sous Dev Cpp avec Windows XP
return 0;
}methodes.cpp
// methodes.cpp
/*=== Header ===*/
#include<iostream>
#include<string>
#include<vector>
#include"classe.h"
using namespace std;
/*=== Constructeur Sousjacent ===*/
Sousjacent :: Sousjacent(float S, float sigma) {
cout << "Construction de l'objet Sousjacent" << endl;
this->S = S;
this->sigma = sigma;
}
/*=== Destructeur ~Sousjacent ===*/
Sousjacent :: ~Sousjacent() {
cout << "Destruction de l'objet Sousjacent" << endl;
}
/*=== Méthode affiche ===*/
// Méthode surchargée avec les méthode Future::affiche() et Option::affiche()
void Sousjacent :: affiche(){
cout << "Spot S = " << S << endl;
cout << "Volatilité sigma = " << sigma << endl;
}
/*=== Constructeur Future ===*/
Future :: Future(string issue_date, string maturity_date, float K, float P, float rendement) {
cout << "Construction de l'objet Future" << endl;
this->issue_date = issue_date;
this->maturity_date = maturity_date;
this->K = K;
this->P = P;
this->rendement = rendement;
}
/*=== Destructeur ~Future ===*/
Future :: ~Future() {
cout << "Destruction de l'objet Option" << endl;
}
/*=== Méthode affiche ===*/
// Méthode surchargée avec les méthode Sousjacent::affiche() et Option::affiche()
void Future :: affiche(){
cout << "La date d'émission est : " << issue_date << endl;
cout << "La date de maturité est : " << maturity_date << endl;
cout << "Strike K = " << K << endl;
cout << "Price P = " << P << endl;
cout << "Rendement = " << rendement << endl << endl;
}
/*=== Constructeur Option ===*/
Option :: Option(string cp) {
cout << "Construction de l'objet Option" << endl;
this->cp = cp;
}
/*=== Destructeur ~Option ===*/
Option :: ~Option() {
cout << "Destruction de l'objet Option" << endl;
}
/*=== Méthode affiche ===*/
// Méthode surchargée avec les méthode Sousjacent::affiche() et Future::affiche()
void Option :: affiche(){
cout << "L'option est un " << cp << endl << endl;
}classe.h
#ifndef CLASSE_H
#define CLASSE_H
#include<iostream>
using namespace std;
/*=== Classe Sousjacent ===*/
class Sousjacent {
private:
float S; // Spot
float sigma; // Volatilité
public:
Sousjacent(float S=0., float sigma=0.); // Constructeur
~Sousjacent(); // Destructeur
void affiche(); // Méthode affiche
};
/*=== Classe Future ===*/
class Future {
private:
string issue_date; //Format : yyyy/mm/dd
string maturity_date; //Format : yyyy/mm/dd
float K; // Strike
float P; // Price
float rendement; // Taux de rendement
Sousjacent action; // Sous-jacent du future
public:
Future(string issue_date="empty", // Constructeur
string maturity_date="empty",
float K=0.,
float P=0.,
float rendement=0.);
~Future(); // Destructeur
void affiche(); // Méthode affiche
};
/*=== Classe Option ===*/
// Cette classe hérite de la classe Future
class Option : public Future {
private:
string cp; // Si il s'agit d'un Call ou d'un Put
public:
Option(string cp="unknown"); // Constructeur
~Option(); // Destructeur
void affiche(); // Méthode affiche
};
#endifDernière modification par aganim07 (Le 05/11/2007, à 16:54)
Hors ligne
#92 Le 05/11/2007, à 20:58
- Link31
Re : Questions sur la P.O.O. (C++ et JAVA)
// Méthode surchargée avec les méthode Future::affiche() et Option::affiche()
Ah bon ? Ni Future ni Option ne sont des Sousjacent, je ne vois pas comment ils peuvent surcharger une méthode de Sousjacent.
// Méthode surchargée avec les méthode Sousjacent::affiche() et Option::affiche()
// Méthode surchargée avec les méthode Sousjacent::affiche() et Future::affiche()
Non plus.
Que penses-tu de ça ?
Future* pOption;
pOption = new Option;
pOption->affiche();Si tu veux vraiment faire un héritage polymorphique, il faut que la méthode affiche() de la classe de base (Future) soit déclarée "virtual" (virtuelle). Pour l'instant, Option::affiche() masque la méthode Future::affiche() mais ne la surcharge pas.
PS : NULL c'est du C méchant pas beau
En C++ on utilise 0 pour les pointeurs invalides.
Dernière modification par Link31 (Le 05/11/2007, à 21:00)
Hors ligne
#93 Le 05/11/2007, à 21:40
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Mais les méthodes Option::affiche() et Future::affiche() sont différenciées par la portée de classe auxquelles elles se rapportent non ? Il y en a une relative aux options et l'autre aux futures. Donc elles sont différentes non ? Je comprends plus là c ce qui est expliqué dans mon bouquin...
De plus, qu'est-ce qu'un héritage polymorphique exactement stp ??
(moi qui pensait avoir tapé un bon code)
Dernière question >
aganim07 a écrit :// Méthode surchargée avec les méthode Future::affiche() et Option::affiche()
Ah bon ? Ni Future ni Option ne sont des Sousjacent, je ne vois pas comment ils peuvent surcharger une méthode de Sousjacent.
D'après ce que j'ai compris, on surcharge une fonction (ou une méthode) quand le libellé de la fonction est réemployée plusieurs fois. C'est donc ça la surcharge. La possibilité de réemployer le nom d'une fonction pour différentes fonctions. Sauf que ces fonctions resteront différenciées par la liste de leurs arguments (nbre et types d'arguments) ainsi que par la classe à laquelle elles appartiennent si ces fonctions sont des méthodes (des fonctions membres quoi, mais je préfère dire méthodes).
Dernière modification par aganim07 (Le 05/11/2007, à 21:50)
Hors ligne
#94 Le 05/11/2007, à 22:47
- Link31
Re : Questions sur la P.O.O. (C++ et JAVA)
De plus, qu'est-ce qu'un héritage polymorphique exactement stp ??
Regarde l'exemple de code de mon message précédent : *pOption est déclaré comme un Future, mais je lui assigne un objet dérivé avec new (un Option). À la troisième ligne, j'appelle la fonction affiche() à partir de *pOption.
- si l'héritage est polymorphique (si Future::affiche() est virtuelle), alors la fonction appelée sera Option::affiche() (ce qui est normal, vu que *pOption est en fait un Option).
- si Option::affiche() ne fait que masquer Future::affiche() (si Future::affiche() n'est pas virtuelle), alors le compilateur appellera simplement Future::affiche(), ce qui est dommage.
D'après ce que j'ai compris, on surcharge une fonction (ou une méthode) quand le libellé de la fonction est réemployée plusieurs fois. C'est donc ça la surcharge. La possibilité de réemployer le nom d'une fonction pour différentes fonctions. Sauf que ces fonctions resteront différenciées par la liste de leurs arguments (nbre et types d'arguments) ainsi que par la classe à laquelle elles appartiennent si ces fonctions sont des méthodes (des fonctions membres quoi, mais je préfère dire méthodes).
En fait, la classe Sousjacent n'a rien à voir avec les classes Future et Option, donc tu peux très bien mettre les noms de fonction que tu veux, elles ne se surchargeront jamais. Deux fonctions sont surchargées si elles sont dans le même espace de noms, ont le même nom et valeur de retour mais des arguments différents.
En l'occurrence, "le même espace de noms" signifie dans la même classe, ou l'une dans un classe de base et l'autre dans une classe dérivée.
Hors ligne
#95 Le 05/11/2007, à 22:56
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Donc deux fonctions ne peuvent êtres dites "surchargées" si elles sont seulement différenciées par leur appartenance à deux classes distinctes.
Crévindjuu je crois bien que mon livre m'a dit des conneries alors... Le livre en question est "Le C++ pour les nuls". Je commence à me méfier de ce bouquin (ou de la façon dont je l'interprète).
'fin bref comme vous le voyez j'apprends mais je suis pas encore un pro !
Hors ligne
#96 Le 05/11/2007, à 23:10
- Le Farfadet Spatial
Re : Questions sur la P.O.O. (C++ et JAVA)
Salut à tous !
Mais les méthodes Option::affiche() et Future::affiche() sont différenciées par la portée de classe auxquelles elles se rapportent non ? Il y en a une relative aux options et l'autre aux futures. Donc elles sont différentes non ?
En effet et alors ?
Une classe est un espace de nommage. De fonctions qui ont le même nom, mais dans des espaces de nommages différents sont des fonctions différentes. En fait, elles ont chacune un nom différent de l'autre. Par exemple, dans ton cas, l'une est nommée Option::affichage(), l'autre Future::affichage(). La notion d'espace de nommage est justement là pour éviter les collisions de nom, donc ici il n'y a aucune surcharge. Voici un exemple simple où il y a pour de bon surcharge :
namespace Exemple {
int max (int x, int y) {
if (y > x) return y;
else return x;
} // int max (int, int)
// Surcharge
double max (double x, double y) {
if (y > x) return y;
else return x;
} // double max (double, double)
} // namespace ExempleCe n'est qu'un exemple. Qui vaut ce qu'il vaut, dans la mesure où, dans ce cas particulier, il serait mieux de faire ceci :
namespace Exemple {
template <class T> inline T max (T x, T y) throw () {
return (y > x) ? y : x;
} // T max (T, T)
} // namespace ExempleMais ce n'est plus tout à fait un exemple simple...
Je comprends plus là c ce qui est expliqué dans mon bouquin...
C'est parce que tu ne lis pas le Stroustrup --- non, je n'ai pas d'action chez Pearson Education.
De plus, qu'est-ce qu'un héritage polymorphique exactement stp ??
Pour faire rapide, le polymorphisme c'est la capacité d'un objet d'instancier une des classes dérivées de sa classe de déclaration. Cependant, mon avis est qu'il est un peu tôt pour que tu abordes ça. La semaine prochaine...
(moi qui pensait avoir tapé un bon code)
Il n'est pas si mal !
NULL c'est du C méchant pas beau wink
En C++ on utilise 0 pour les pointeurs invalides.
Je me lève et j'approuve. Cela dit, aganim07, c'est une bonne chose de penser à mettre les pointeurs qui ne sont plus utilisés à zéro, trop souvent on oublie de le faire.
Les std::string, il vaut mieux les passer en référence constante :
Code:Option::Option(const std::string& issue_date, const std::string& maturity_date, float K, float P, float rendement)
Ça évite qu'ils soient copiés pour rien. Le gain de performance est assez négligeable, mais autant s'habituer à de bonnes pratiques. Quand tu devras passer une image de 150 Mo en paramètre, tu verras que ça peut être utile (c'est un exemple, ton programme plantera bien avant d'avoir pu faire rentrer 150 Mo dans la pile wink).
J'approuve encore. Sait-on jamais : si tu fais de la simulation, en tout cas du calcul, tu risques d'avoir besoin de transmettre des matrices. Pour ma part, le plus gros que j'ai fait, ce sont des matrices 100000*100000 et je n'ose pas imaginer ce qui se serait passé si j'avais transmis ça par copie...
À bientôt.
Le Farfadet Spatial
Hors ligne
#97 Le 05/11/2007, à 23:19
- Le Farfadet Spatial
Re : Questions sur la P.O.O. (C++ et JAVA)
Re-salut à tous !
Bon, ben voilà : le temps que je rédige mon message, Link31 a déjà répondu. Je suis une fois de plus le « h » de Hawaï...
Toutefois :
Deux fonctions sont surchargées si elles sont dans le même espace de noms, ont le même nom et valeur de retour mais des arguments différents.
Une question. Ce n'est qu'un détail, mais bon : pour ma part, je parle de surcharge même si le type de retour est différent. Typiquement, je parle de surcharge de l'opérateur d'affectation même si le type est différent que les autres affectations et pour cause :
class Classe {
// Ici, tout plein de chose, c'est une classe
// ...
Classe &operator = (Classe a) throw () {
// Ici les instructions pour l'affectation des différents membres de la classe.
return *this;
} // classe operator = (classe, classe)
// Le reste de l'implémentation de la classe
} // class ClasseDans cet exemple, le type est différent de l'affectation sur les int, par exemple et pourtant je parle de surcharge. Peut-être suis-je dans le faux...
Là, je suis chez moi et j'ai laissé mon exemplaire du Stroustrup au labo, mais je vérifie demain.
Crévindjuu je crois bien que mon livre m'a dit des conneries alors... Le livre en question est "Le C++ pour les nuls". Je commence à me méfier de ce bouquin (ou de la façon dont je l'interprète).
Puis-je te conseiller un ouvrage ?
À bientôt.
Le Farfadet Spatial
Dernière modification par Le Farfadet Spatial (Le 06/11/2007, à 00:59)
Hors ligne
#98 Le 06/11/2007, à 09:54
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Puis-je te conseiller un ouvrage ?
À bientôt.
Le Farfadet Spatial
Oui.
Hors ligne
#99 Le 06/11/2007, à 11:38
- aganim07
Re : Questions sur la P.O.O. (C++ et JAVA)
Au fait, pensez-vous que j'ai acquis un bagage suffisant pour réussir un entretien pour une mission en développement C++ ?
Quel est le style de question qu'un recruteur peut poser pour vérifier les compétences d'un candidat en C++ ?
Merci
Dernière modification par aganim07 (Le 06/11/2007, à 11:39)
Hors ligne
#100 Le 06/11/2007, à 12:05
- Luc Hermitte
Re : Questions sur la P.O.O. (C++ et JAVA)
Salut,
Au fait, pensez-vous que j'ai acquis un bagage suffisant pour réussir un entretien pour une mission en développement C++ ?
Quel est le style de question qu'un recruteur peut poser pour vérifier les compétences d'un candidat en C++ ?
Tout va dépendre de comment tu te vends, et de ce qu'ils cherchent.
J'ai envie de dire qu'il vaut mieux être honnête. Le C++ est un langage difficile, et ceux qui le connaissent le savent pertinemment.
Sinon, je m'étais déjà exprimé, ainsi que d'autres personnes, par là:
http://www.developpez.net/forums/showthread.php?t=354056
PS: c'est bien une surcharge
PPS: C++ pour les nuls est un mauvais bouquin (Accelerated C++ est très bien si tu lis l'anglais technique -- contrairement au farfadet, je ne conseille pas le livre de Stroustrup pour apprendre le langage, juste pour avoir une référence sous le coude)