Construction depuis un entier. Par exemple pouvoir faire qqch comme:

Fraction a(12);

Construction depuis une chaine: Non. Juste le cas simple est demandé. Mais si tu veux faire plus, libre à toi. Mais il devient rapidement difficile de fixer une limite.

OK merci.
J'essairais de commencer ce week-end. Pile-poil pour mon interro de maths (ha la seconde ), qui ne portera pas sur les fractions, hélas.

la construction a partir d'un entier reviens à la construction à partir d'un float, non?

Disons que l'on peut passer un entier dans le constructeur:

Fraction::Fraction(double x)

mais cela a deux (au moins !) désavantages:

1) On a une conversion implicite d'un type dans un autre. Mais ici c'est pas trop grave.

2) La construction depuis un entier est très simple. Depuis un double, c'est plus compliqué.

Mais la construction à partir d'un entier demande moins de traitement, non ? [ J'espère sinon je suis bon pour retourner en cours pendant les vacances . ]

EDIT: J'ai ajouter un constructeur à la liste. Cela devrait vous simplifier le travail.

Citation : Nanoc

EDIT: J'ai ajouter un constructeur à la liste. Cela devrait vous simplifier le travail.

Alors ma remarque perd son utilité. Merci.

Cela "ne sera pas nécessaire" uniquement s'ils implémentent bien l'addition sous forme d'un opérateur libre. Sans cela, ils vont avoir quelques surprises.

@raphamil, si ta construction foire, ou si tu construis avec un dénominateur nul, => exception!

Est-ce qu'on est obligé de respecter la convention m_nomAttribut pour les attributs de la classe ? J'ai plutôt tendance à y accéder avec this->attribut.

Citation : raphamil

Est-ce qu'on est obligé de respecter la convention m_nomAttribut pour les attributs de la classe ? J'ai plutôt tendance à y accéder avec this->attribut.

Ce que tu as écris n'est pas équivalent.

Le nom que tu donnes a ton attribut importe peu. Mais y acceder via this est une erreur. C'est plus lent et c'est inutile. (Tu fais du JAVA ?)

Sinon, pour les exceptions (bonne initiative), tu peux utiliser le type standard std::runtime_error par exemple ou tout autre de tonc choix.

Bon tant pis.
Merci pour cette réponse Nanoc. Je trouve juste ça plus clair (beaucoup d'autres langages le font self.attr );
J'avance bien Le coeur de la classe est terminé (simplification, construction à partir de 2 entiers || d'un double (je me casse la tête sur celui avec la std::string)).

Par contre, je ne comprends pas comment mon code fonctionne (oui je sais je suis bizarre) (mais il marche) :

Ce n'est pas plus lent. C'est plus lourd à taper, et obligatoire pour les templates.
C'est juste que la convention (et ce n'est rien d'autre) m_lowerCamelCase est assez répandue pour les variables membre.

je suis même pas sur qu'on puisse parler d'une convention là...

Si je ne m'abuse, Stroustrup, dans son livre, préfère la syntaxe sans le this->. [J'ai pas été vérifier.]

est ce qu'on doit fixer le taux de precision des float?
sinon y a t il un moyen de savoir le nombre des chiffres apres la virgules?

@ raphamil: http://www.siteduzero.com/tutoriel-3-3 [...] ceptions.html §Gérer une exception dans un constructeur

Citation : lmghs

Ce n'est pas plus lent.

Il me semblait qu'on payait un dereferencement. Mais tu as certainement raison, le compilateur doit optimiser.

Citation : Bachir ElMagnifico

est ce qu'on doit fixer le taux de precision des float?

Je comprends pas la question.

Citation : Bachir ElMagnifico

sinon y a t il un moyen de savoir le nombre des chiffres apres la virgules?

Regarde dans la doc. Et puis, si jamais, ce n'est pas bien difficile à programmer.

Citation : raphamil

Est-ce qu'une exception déclenchée dans un constructeur doit annuler la création de l'objet ?

Hiura te donne la reponse.

Citation : Bachir ElMagnifico

sinon y a t il un moyen de savoir le nombre des chiffres apres la virgules?

Nanoc: lorsque tu dis qu'il faudrait s'intéresser aux cas " "Fraction + Entier" ou "Reel + Fraction" ", ne me dis pas qu'il faut déclarer tous les opérateurs en double . J'en ai déjà une vingtaine avec ceux de comparaisons.

Voilà l'erreur donc parlait lmghs.
Tu n'as qu'a implémenter "Fraction operator+(const Fraction &Lhs, const Fraction &Rhs);"

Est-ce que tu accepte ce genre de trucs :



Parce qu'après c'est lourd à mettre dans le .cpp.

Merci de pas dévoiler tout le code non plus.

Sinon, comment tu veux faire autrement ?

Pour les opérateurs, Chlab_lak t'as donné une solution. C'est aussi pour ça que j'ai mis "réfléchir à".

OK-OK je mets en secret
Ce que je voulais dire c'est mettre certaines définition de fonctions dans le .h.

Et ce genre de machin illisible ?

Si tu as pas mal de problèmes, je te conseilles de faire une nouveau thread pour ça.

Le dernier truc est sale, dur à maintenir et sans intérêts ici.

PS: je ne vois pas ce que vient faire le PGCD en propriété d'un nombre rationnel, ni pourquoi ce nombre aurait des fonctions membres PGCD et PPCM. Ces fonctions existent en dehors de toute notion de nombre rationnel.
J'ai bien une adresse de solution où vous envoyer (pour voir l'interface type par des pros), mais l'exo perdrait un de ces intérêts.

Citation : lmghs

J'ai bien une adresse de solution où vous envoyer (pour voir l'interface type par des pros), mais l'exo perdrait un de ces intérêts.

Pourrais-tu la communiquer à Nanoc pour qu'il la donne avec la solution ?

Je serais surpris qu'il n'ait pas connaissance de cette suite de bibliothèques qui booste notre productivité.
(pour continuer dans le second degré <rot13>vy l n har pynffr qr zêzr pbzcyrkvgé qnaf yn ovoyvbguèdhr fgnaqneq</rot13>)

Je vois tout à fait à quoi il fait référence.

<rot13>GBA PELCGRHE TRER ZNY YRF NPPRAGF</rot13>

Purm zbvyrf nppragfg qr fba pbqr znepur cnesnvgrzrag
fvaba, nhgnag hgvyvfre yn zc cyhgbg dh'ha zrffntr pelcgé