Voilà, je travaille depuis qqs jours sur une classe de grands entiers, et bon pour surdéfinir les opérateurs pas de problèmes. Par contre j'ai voulu surdéfinir qqs fonctions existantes :
comme la fonction 'abs' qui fonctionne à merveille avec mes grands entiers(class Top),

 
 
par contre il y a des problèmes lorsque je veux surdéfinir la fonction pow

 
et voila ce que le compilo m'envoie en erreur :  

 
ceci est du à l'appel de pow de la manière suivante :
pow(2,100000);
 
en fait le compilo voit un conflit car il peut convertir le 2 en Top grâce au constructeur Top(int) ou bien utiliser son pow natif pow(int,int)
comment fais-je ?
 
faut-il que je créer la fonction puissance en tant que méthode, ou bien que jechange son nom de fonction ? ça m'embête un peu qd même...

Tu ecris pow(BigInt(3),10000); ou alors tu change de nom de fonction

 
Je te conseille de ne pas utiliser cette notation qui n'est pas objet, mais d'utiliser la notation objet : monint.pow(other).
 
Tu wrappe tes entier dans une classe Integer (fait gaffe à éviter les références car ta classe est toute petite) avec une méthode pow(Integer) et une méthode pow(Top), tu mets les mêmes méthodes dans Top.
C'est pas complètement objet mais ça aura exactement la sémantique de ce que tu veux faire.
 
Pour carrément tout planquer proprement et de façon objet (le passage de small vers big), j'ai écris un article dessus pour ma promo : http://nraynaud.com.free.fr/td3dispatching.html n'oublie pas qu'en C++ il faut utiliser "virtual" partout pour que ça fonctionne.

en fait j'aimerais garder l'écriture conventionnelle, et pour l'exemple que tu me donnes, c'est pas tout à fait ça que je veux, mais utiliser le pow(int,int) si j'appelle pow avec un int et pow(Top, int) si j'appelle avec un Top
 
 

en gros ce serait créer la classe Int en java, et euh par contre je vois pas trop pourquoi éviter les références quand une classe est petite ?
 
 
 

 
je vois ce que ça donne, mais c'est pas tout à fait ça que je voulais, car je serais quand même obligé de typer le int en Integer...M'enfin bon, je vais tenter d'arranger ça. Merci pour le lien

Ah bah, si c'est ça c'est facile alors
 
http://www.glenmccl.com/tip_023.htm
 

kweel ! merci kristoph ! c'est exactement le mot qu'il me fallait, explicit   j'y ai pas vraiement cru au début, et puis si en fait, c'est parfait. j'ai failli devenir   pendant un moment, et puis retour à l'état normal  

Je pense pas que ce soit ça exactement, il choisirait 'pow(int,int)' directement sans ambigüité.
Le pow C est 'pow(double,double)', le pow stl utilises des complexes.
 

Je ne le conseille pas.
Cela empêcherait d'écrire du code générique utilisant indifféramment les types de base ou utilisateur.
'pow' est une fonction ou un algorithme avant d'être un attribut du type.
 
Tu vois toujours des objets partout.
Celui qui n'a qu'un marteau comme outil vois tous les problèmes comme des clous.

 
J'ai donné la méthode pour écrire du code générique 46 000 fois, et la méthode pour l'étendre sans tout réécrire et sans tout revalider, ça commence à me gonfler, le C++ est fait pour faire de l'objet, pas pour faire n'importe quoi et se demander pourquoi ça marche pas ensuite. Si des tocards ont décidé de garder des types primitifs dans leur langage soit-disant "de haut niveau", je n'y suis pour rien, c'est pas une raison pour plier l'échine et conseiller de faire des conneries à n'importe qui sur le net sous-prétexte d'un pseudo-anonymat.
 
Concernant ma limitation d'esprit à l'objet, je peux te trainer très loin dans l'applicatif (souvent appelé fonctionel) sans sourciller, j'en suis quasiment certain, sauf que je ne vois ni de forum ni de questions pour en parler ici, c'est tout simplement pas à la mode (bien malgré moi).

 
C'est normal, il fait partie de la secte de Bertrand Meyers. J'en connais pas mal d'autres comme ça
 
Mais il a raison sur ce point, c'est bien ave pow(double, double) qu'il i a conflit. Il te suffit de ne pas include cmath pour être tranquille. Si vraiment tu as besoin de cmath il ne te reste que à lever toi même l'ambiguité.

bah, ça marche avec le mot-clef explicit, alors    

sinon nraynaud, je suis d'accord avec toi sur le fait que le c++ c'est fait pour faire de la prog objet. Mais là, ma classe, je compte l'optimiser à fond, quand je l'aurai bien travaillée et totalement finie, je commencerai à passer des instructions MMX(mais c'est pas objet là-dedans ? tu me diras autant coder en C) Mais bon, quand ma classe sera terminé, elle sera très simple d'utilisation, après tout, je garde la notion d'encapsulation, peu importe si j'utilise de l'ASM après à l'intérieur de la classe,(les gains seront assez énormes, G fais qqs tests, vu que je n'utilise pas les regsitres FPU, je peux optimiser en MMX
pour l'opérateur multiplication, ça va bien m'aider, et puis cette classe Top, je vais la maltraiter par la suite, (construction de matrice de Van Der Monde conçue sur ma classe Top, recherche d'équation de polynomes à partir de coordonnées de points). Voila, donc je suis tout à fait conscient de réaliser un code "batard", ne vous inquietez pas  
le proc va chauffer

A mon avis, tu ne devrait pas mettre explicit sur ce constructeur car c'est dans ces situations que les conversions implicites sont utiles. Tu devrais plustot renomer ta fonction pow ou la mettre dans un namespace adapté. Et la ou il y a conflit, l'utilisateur devra lever lui même l'ambiguité en fesant des cast explicites.
 
Sans explicit : toute fonction qui attend un Top peut etre appelée avec un int et C++ fera la conversion à la main.
Avec explicit : toute fonction qui attend un Top doit recevoir un Top et donc tu devras mettre à la main les appels de constructeur.
 
Quite à choisir, je prefere la première solution surtout qu'il est facile pour toi de differencier ta fonction pow de celle de cmath.

je crois ke je v suivre ton conseil en fait, j'avais pas pensé à ça  

Pas seulement. Le créateur du C++ parle du multi-paradigme.
 

Pour des raisons de performances peut-être ? En Java c'est pareil.
Cela dit, si on ne peut pas en dériver, c'est à cause de leur comportement historique (promotion, entre autres).
 
Pour le fonctionnel: J'apprendrais ça plus tard. C'est pas en C++ que je pourrais le faire.
 
Et puis tu t'énerves trop, c'est pas bon pour la santé. Kip cool.
 
 
Mais je comprends pas...

Il considère comme également éligibles une conversion utilisateur et 2 promotions de type intégré ?
Il me semble qu'une seule conversion est priotaire sur deux...

Mettre des priorités sur les conversions implicites c'est mal en fait, car ca rend le système difficile a prédire pour l'utilisateur. En cas d'ambiguité il vaut mieux la laisser en place  que de faire un choix arbitraire. "Explicit is better than implicit", sauf quand ce n'est pas ambigu