bon g mis le code en bas , c pas propre y a des dechets etc.
Alors mon probleme ce trouve au niveau de la surcharge de l'operateur+ .
il y a la class entier dont derivent par heritage les entiers_court puis les entiers normaux, et les entiers longs.
Je voudrais que a+b renvoit un objet du type de a ou même b.
le probleme est que même si je créé un entier_court x avec a et b que je veux le renvoyer avec le return, vu que mon type de retour de la fonction est entier, et bien il me fait une espece de cast automatique et transforme le x en entier , mais moi je veux pas.
 
En fait y a pas moyen de selectionner le type de retour de la fonction. Moi je pensais qu'il m'enverrai l'objet x intact mais nan il fait une conversion du type de x.
Comment empecher cette conversion ?
Merci.
 

Moi, j'aurais surchargé l'operateur+ dans chaque classe fille.
Ca fait plus de code, mais tu es sur de ton type de retour (bon en fait ca s'appelle contourner le probleme).

 
Vi j'y ai pensé, mais je me disais que y avait ptere un autre moyen.

 
ton typeof() est calculé statiquement, donc il prendra statiquement la valeur entier.
 
Tu as besoin du pattern Double-dispatch : tu dois répertir chaque classe sur une autre pour écrire les règles de calcul entre 2 instances de classes différentes.
 
tout d'abord, commence par extraire ton interface :
tu dégage une classe AbstractEntier
 
tu lui fout (AbstractEntier &) operator +(AbstractEntier &) et (AbstractEntier) operator =(AbstractEntier &)  et peut-être des méthodes d'accès au limites tout le monde en virtuel = 0 (méthodes abstraites).
 
ensuite, tu crées tes sous-classes distinctes, Entier, EntierLongSigne etc. (y'a peut-être moyen de dégager quelquechose par rapport à signé/non signé mais c'est pas le sujet).
 
Et c'est là que tu vas utiliser toutes la puissance de l'objet, mais comme le pattern en question je l'ai déjà écrit pour plein de monde (en plus pour ce cas-là !!), tu vas sur http://nraynaud.com.free.fr//td3dispatching.html et tu vas suivre les conseils (en traduisant le java en C++ donc toutes tes méthodes doivent être virtuelles, c'est là-dessus que repose tout le pattern).  
Et tu auras ainsi ton "vocabulaire de conception" d'un nouveau pattern natuerellement car tu avais un problème et ce pattern est là pour le résoudre.
 
edit :  
c'est sur que si t'es un gros flemmard, y'a des techinques de porc qui te permmetent de ne pas écrire n^2 méthodes (n étant le nombre de classes) mais dans ce cas, le principe ouvert-fermé tu te torches avec.

Avec le retour covariant du C++ (qui doit arriver dans java 1.5 je crois) il doit être possible de faire mieux non ?

 
Benh ça je suis pas sur car j'ai mis des methodes pour tester, et x prend bien le type de l'objet this.
 
 

 
hem g pas compris grandchose là  
C'est pour un projet de licence info.
Je lis la page td3, je vais voir si ça m'aide.
Merci.

Et fout-moi du const un peu partout aussi, par ex, tu t'engage à pas modifier le paramètres du + mais à construire un nouvel objet pour le résultat. De même en règle générale, dans tout ce qui est maths on ne fait pas d'effets de bords (en tout cas rien qui se voit, un petit cache par-ci par là éventuellement, mais rien de visible pour l'utilisateur).

 
Comme dirait ma prof, il faut blinder      
Faudra qu'on m'explique un truc.    
A partir du moment ou on sait que on ne va pas modifer l'objet passé en paramtre ça change rien si met const ou pas ... a part pour blinder      
De même fo qu'on m'explique le "rien de visible pour l'utilisateur" je comprend pas ce que l'utilisateur peut voir si c'est compilé, mais bon  
 
Enfin j'ai rien compris au td3, et je suis un peu a la masse en java, mais bon je comprend pas vraiment là.

Utilisateur du composant (fonction, objet, ...) que tu ecrit... Ca peut être une autre partie du programme, pas forcément un être humain

Oui enfin, je parlais de contrats, pas de conde défensif (blinder cétait pas clair).

Const "teinte" le paramètre passé en argument, tu ne pourras pas appeller sur lui des méthodes qui ne sount pas const et l'affecter à de variables qui ne sont pas const, affecter son adresse à des mointeurs qui ne sout pas const etc.
En gros, tu as la ganrantie de bout en bout que le paramètre ne sera pas modifé. Et ceci est vérifié par le compilateur, tu n'as donc pas de risque d'érreur humaine. Si tu le mets pas, tu risque de le passer en paramètre d'un truc qui au fin fond de la pile d'appel (après 15 appels de fontions et une distance parcourue énorme) va le modifier.
Tu peux ne pas le mettre mais déjà que le C++ ne fait pas grand'chose pour la qualité alors le minimum est d'utiliser ce qu'il y a.
 

L'utilisateur d'une classe est celui qui va l'instancier, en général, le gars qui n'a accès qu'à la doc et au .h. Lui doit savoir des truc et doit en ignorer d'autre, ceux qui sont suceptibles de changer, sur lesquel le concepteur ne s'engage pas etc.
S'il y a présence de caches par exemple, l'utilisateur n'a pas à le voir (par des paramètres bizarres, par des interfaces etc.).
 

 
Heu là si tu poses pas de questions précises, je vais réécrire ce qu'il y a dans le TD en C++ adapté à ton cas et ça ne va pas te servir à grand'chose.
 
Je tente de réexpliquer la démarche :
 
En gros le principe est de maîtriser les opérations entre 2 objets de type différent, pour le faire, il faut déjà décider pour chaque couple comment on va faire (caster qui vers qui, algorithme etc...). Comme tous ces types auront une interface commune (la possibilité de s'additionner entre eux etc.), on l'isole, d'où la présence d'un classe abstraite au plus haut  
niveau.
Ensuite, il faut créer les sous-classes concrètes qui vont te servir, toute héritières de la classe abstraite.
 
Tu créés dans chaque sous-classe les méthodes implantant les décisions prises au début : si je reçoit un objet de type machin et comme je suis moi-même de type bidule alors je calcule comme ça. C'est les méthodes du style :
 const AbstractEntier ajouterEntierLongSigne(const EntierLongSigne &bidule) const {...}
 
Tu en as nombre de classes^2 à écrire par opérateur (fait gaffe, c'est le double pour les non-commutatif, je t'en parle à la demaonde). Tu remontes enssuite leur prototype dans la classe abstraite, le principe de base est que tu _sais_ que tout le monde sait s'additionner avec tout le monde.
 
ensuite, il faut que la bonne méthode soit apellée à partir de (par ex.) +, c'est là qu'est la feinte d'apeller sur l'objet autre à droite du + (dont tu ne connais pas le type précis mais dont tu est sur qu'il sait t'additionner toi) la méthode autre.ajouterMaClasse(*this) car toi tu sais que tu est de type MaClasse et l'autre le saura car sinon tu n'aurait pas apellé cette fonction (et tous les types des paramètres à utiliser sont donnés dans le TD).
 
Bon, lis et reviens avec des questions.

ok je vois mieux.
Mais en fait je pensais que y aurait moyen de s'en sortir sans devoir redefinir l'operateur+ dans chaque classe.
Disons que quand on renvoit un pointeur sur un objet, on peut renvoyer une objet derivée d'une classe de base bien que le type de retour soit cette classe de base. Dans ce cas, le type de l'objet retourné n'est psa modifé, sauf que pour que les methode des classes derviées soient appelées, il faut du virtual dans les classes superieurs.
Mais la apparement la conversion de l'objet de classe dérivée en la classe de base ce fait quand même, et ça je comprends pas.    
Si l'objet retourné est plus specifique que le type retourné, et bien il doit pouvoir etre retourné tel quel vu que il contient toutes la carcteristiques de la classe de base. Comme c'est le cas lorsque l'on retourne un pointeur sur un objet.
 
Vois tu ce que je veux dire ?

tu peux redéfinir + uniquement dans le classe la plus haute et appeler une fonction plus(nb,nb) dedans si tu veux, mais c'est pareil (hormis que tu utilises le pattern template method).
 

Je ne pense pas qu'il y ait conversion réelle, tout simplement car le compilo n'aucune idée de comment passer de l'un à l'autre (et moi non plus d'ailleur) par contre, le contenu de ta variable sera _vu_ comme s'il était de la classe de base. ça rejoint la remarque de lorill ici :  
http://forum.hardware.fr/forum2.ph [...] h=&subcat=
 

C'est retourné tel quel, je ne vois pas le problème.
 
Je viens de relire ton post original, c'est des types ancrés que tu veux faire, ça n'existe pas en C++ (on peut approcher en bidouillant avec typeof mais on est très loin encore), uniquement en Eiffel à ma conaissance.

bon benh si c'est retourné tel kel, et bien je ne comprend pas pourquoi l'objet retourné même si il est du type entier_court_signe par exemple, et bien apres etre passé dans le return, c'est un entier, et même ses bornes mnimum et maximum qui sont censé rester a -128 127 et bien ce retrouvent avec les valeurs 2147483647 ,  -2147483648 qui sont les valeurs par defaut si on appelle le constructeur entier. (ok c pas possible il devrait etre abstrait et en plus les bornes sont fausses ou du moins n'ont pas de signification vu que c'est censé etre une classe abstraite).
C'est donc pour ça que j'ai fait la methode bo() pour comprendre ce qui ce passait en effet cette methode renvoit le type de l'objet.
 
 
en fait ce qui me fait halluciner c'est que ce qu'il me renvoit, c'est comme si il construisait un entier de cette façon : entier bidule (valeur)
donc même si je retourne un entier_court_signe sur le type entier, il le transforme entier par je ne sait kel miracle, et lui donne la bonne valeur numerique mais plu le bon type.
Tu n'as pas l'air convaincu par cela mais pourtant c'est ce qui ce passe et j'en suis le premier etonné.
Peut etre que c'est le constructeur d'affectation par defaut qui entraine cela.    
 
Un autre truc qui m'a vraiment bluffé, c'est que je n'ai pas surchargé = et pourtant quand je fait :  

et bien le champ valeur de l'objet a vaut 24    
   
 
Merci pour ton aide.    

Tu devrais vraiment commencer à concevoir proprement, virer tout code effectif de la classe du haut. Tu te posera moins de questions.

Ça ne marche que par référence/pointeur, et là il faut qu'on retourne un objet.

Il faudrait penser aussi à un truc qui s'apelle le standard...

Quand à ça...
D'abord les constantes remplacent les defines en C++.
Ensuite, pas la peine d'inventer ces nombres, ils sont fournis:
numeric_limits<signed char>::max()
 
 
Bon, pour ton problème je propose simplement un opérateur binaire séparé:

Je n'ai pas pu tester complètement (mon compilateur me vomit 'INTERNAL COMPILER ERROR' sans raisons).
 
Je crois qu'il y a moyen avec les patrons aussi, mais adieu la hiérarchie.

le sert a koi cette ligne ?
 
sinon au niveau du codage propre fo pas trop en demander, car ça fait 2 mois que je connais c++ et j'avais jamais fait de c avant. C'est une incoherence de la fac.

 
elle rappelle le constructeur du dessus pour initialiser les champs que tu serais incapable d'initialiser en bas.
la même notation sert à initialiser un champ de ta classe :
 

 
à quoi ça sert puisque l'affectation peut le faire ?

 
et ben voilà une partie de la réponse.
 
sinon, cette notation n'appelle pas l'opérateur = donc s'il est surchargé par un truc super lent, il ne sera pas appelé (on serait bine dans la merde avec un this->instvar qui n'a pas de valeur définie).
 
donc notation initialisation, différente de la notation affectation. Elle permet d'appeler les constructeurs du dessus (qui vont initialiser les variables d'instance définies au dessus) et les variables d'instance de cette classe.
 
Voilà, une notation de plus avec sa sémantique, tu progresses sur la route du C++ (beuark).
 
Sinon, je suis assez pour faire apprendre aux gens le C++ sans prendre les mauvaises habitudes du C d'abord. Il faut y aller progressivement (ce qui sembe ton cas vu que tu ne maîtrises pas encore const et la notation initialisation), c'est tout.
Par contre, je préfèrerais faire apprendre l'objet sur un langage où la grammaire n'est pas un problème : smalltalk. Il n'y a rien commme notations vicieuse là dedans, et tout est à l'exécution, on se concentre sur l'essentiel : la conception objet.

Il ne faut pas trop etre exigent sur le plan coherence pedagogique en fac.

C'est clair que la syntaxe du C++ est... spéciale (soyons gentils).
Si le but est d'apprendre l'objet, il n'est pas 'pur' non plus.
Je pense qu'on peut faire le C avant le C++, mais que ce n'est vraiment pas la peine de s'y attarder.
 
Bref, malgré des défauts encombrants j'aime le C++ pour sa puissance d'expression.
 
 

Je me suis trompé en mettant ça, le typage reste statique: 'entier'.
Il faut bien garder une fonction virtuelle:

Ou alors il existe une feinte ?

 
Pourquoi ? c'est de l'objet, c'est propre (ça repose sur la liaison retardé), c'est un pattern connu (template method), je ne pense pas qu'il y ait mieux (en dehors de virer la surcharge de << mais c'est pas ta question).
 
Par contre la hiérarchie aïe ! Elle passe pas 10s à l'écriture du contrat. Ni aux métriques de Martin (ségrégation des interface, inversion des dépendances).

Je m'étonne simplement que quand on lui passe un objet, typeid() ne regarde pas son type dynamique (s'il existe).
Ça y est, je viens de comprendre... j'avais enlevé toute fonction virtuelles, donc adieu le RTTI pour entier.
Il suffit donc de mettre une fonction virtuelle de recherche de nom pour qu'on n'en ait plus besoin !
 
Voilà, c'était le truc idiot du jour...
 

Tching thang thoung ?
Pour répondre à ça, il va falloir que je passe un peu de temps à potasser les termes POO.
 
Mais le code que j'ai balancé, c'est juste un début de correction, je n'aurais pas fait comme ça de toutes façons.

 
Puis-je juste te suggérer de ne jammais utiliser ça en dehors du débogage, dignostique d'erreur ou exploration (si ça existe en C++, jamais vu avant smalltalk) ou de menaces de mort crédibles ?  
 

 
tiens, pour t'aider :  
http://www.objectmentor.com/resour [...] .%20Martin
Les publications de Robert C. Martin, j'ai tout lu mais malheureusement, tout n'est pas intégré (en gros je suis pas satisfait de mon code).
 
 
Pour les contrats, la conception et la qualité, le meilleur livre de l'univers :
http://www.eyrolles.com/php.inform [...] 2212091113
c'est 60 euros _très_ bien investis.
 
 

autrement g une question.
J'avfais tenté de surcharger l'operateur+ mais en amis.
De cette maniere je pouvais faire entier+entier.
J'ai fait ça :
 

 
avec dans le main ça par exemple et aussi diferentes modifs dans le prog :
 

 
Sauf que operator+ veut pas des pointeurs      

 
ET SI avant que quelqu'un ne réponde à ta question, tu commançais par oublier l'existance de l'opérateur typeof() ?
 
Tu aurais fait un grand pas vers la connaissance !

 
mouerf.
Mais bon oublions le type of.
Ici ce que je veux souligner c'est que apparement operator+ veut pas de pointeurs en parametres, je vais pas faire un autre topic pour ce "probleme". Ici je veux juste savoir pourquoi on peut pas mettre de pointeurs sur le +.
Sinon c koi le prob avec le typeof ? Etant donné que je voudrais creer un objet du type d'un des deux passé en params comment faire autrement ?
Franchement t'haluccinerais si tu voyais les bidouilles des autres personnes   .

 
normal, la syntaxe c'est :  

 
le mode normal qui recopie sur la pile ou :

 
le passage par référence (qui s'utilise avec un point).
 
Come ton niveau monte, utilise const :

 
pour dire "je m'engage à ne pas modifier mes entrées".

 
Attend tu ne me parles pas sur ce ton là s'il te plait.    
Je viens d'avoir 15 a mon CC d'objet  
 
 

 
Mais ça marche pas ce que tu m'a donné.  
Ici ce que je voulais c'est que operator+  prenne en parametre des pointeurs sur des entiers et renvoit un pointeur sur un entier et pas prendre des objets entier et renvoyer un entier.
(je sais ça risque d'etre tres porc pour supprimer les objets mais bon   ).

 
Tu veux que je te présentes mon ancien prof d'objet ? il nous filait comme exemple :
 

 
(en smalltalk).
 
Donc avoir 18 à son interro c'est pas dur !
ça ne veut absolument rien dire par rapport à ton niveau réel.

 
Je fait du c++ depuis 2-3 mois, tout est relatif.
C'etait pas tres dur non plus.


 
Sinon tu n'as pas repondu a ma question, pkoi c pas possible de mettre des pointeurs en parametre dans operator+ ?

 
parce que pour l'utiliser, il faudrait que tu écrives :
 

 
 
et ça devrait marcher mais c'est hyper lourd.
 
alors que, à l'utilisation, les références sont prises et déréférencées sans que tu n'aie de syntaxe particulière.

 
bah non ça marche pas.
Ormis d'autres erreurs, la premiere erreur a la ligne en grad est la même.
Je ne m'y connait pas vraiment mais je trouve ça surprenant et dommage.

 
Va vraiment falloir que j'arrête la drogue !
C'est évident que ça pouvait pas marcher : l'addition de pointeurs n'a aucun sens, c'est l'addition d'un pointeur et d'un entier qui en a (accéder à l'élément de rang n après le pointeur).

 
Cette ligne est assez marante.
Sinon ok l'addition de deux pointeurs a pas de sens. Dans le sens ou effectivement on peut additioner un nombre a un pointeur ou l'incrementer.
Je suis tout a fait d'accord que additioner les valeurs de deux adresses a pas de sens.
Par contre l'addition de deux objets designés par leur pointeur a un sens !
L'addition de leur contenu a un sens. Sauf que là c pas possible .
Le probleme vient du fait que on pourait croire que c'est ce qu'on veut faire, mais non ce qu'on veut faire des pointeurs nous regarde   .
A partir du momment ou on sait que additioner deux pointeurs (les adresses) est ridicule il suffirait qu'il implmeente pas ce prototpe opertor+(x*,x*) et nous permettre de le faire si on veut. Je vois pas pourquoi par contre on peut pas le surdefinir. Techniquement rien ne l'empecherait.
Je dois pas comprendre un truc.    
 
D'ailleur je me demandais, est qu'on peut surdefinir operator+(int,int) ?
 
Par exemple :
int operator+(const int &a,const int &b)
{
return a*b-1;
};
 

 
bon ok je sors    

oui et ça sécrit :
 
*i + *j  
 
 

 
ben simplement, ajouter l'adresse de 2 cases mémoire n'a pas de sens donc c'est pas possible.
 

 
je suppose que oui, teste !

 
oui mais ajouter deux objets commençant a tel case memoire devrait avec nos propres regles ça devrait etre possible. D'autant plus qu'on connait le type.bref ... Ca aurait simplifié les choses.

 
Le principe de la surcharge n'est pas de modifier le comportement d'un opérateur mais d'adapter son comportement à une réalité qui a un peu changé. Si "de base" ça fait un truc, sur un truc plus évolué, ça doit faire _le même_ de la façon adaptée. Le but n'est pas de changer le comportement des opérateur (préservation du contrat). Donc si "de base" ça n'a pas de sens, tu n'a pas de droit de lui en donner un, tu changerais son sens.

c'est ridicule.
Si un objet peut etre identifié a travers son pointeur, dans ce cas y a pas de raison qu'on puisse pas ce servir de la surcharge du + pour additioner deux objets au travers du pointeur.
Ca eviterait de devoir faire *a+*b et en plus ça permettrait de faire facilement ce que j'essayait de faire dans mon prog.
Dans la mesure ou l'adddition des adresses contenue dans deux pointeurs est pas autorisée, je vois pas pkoi les concepteurs ne ce sont pas gardé la possibilité d'additioner deux objets en ne connaissant que leurs pointeurs et leur type. Ca me semble logique ou du moins allant de soit. Dans la mesure ou ça aporte d'autre possiblité je vois pkoi faudrait s'en priver.
le contrat et tout ça c'est du blabla je trouve quand on voit a quel point le c++ est quand même un langage de bidouille.