SAlut,
 
 
pour écrire un float ou un double , un réel quoi en somme, il faut utiliser la syntaxe  
2.3f, avec le f à la fin , où c'est inutile en C++ ?
 
Merci.

double foobar = 3.14;

std::cout << foobar << std::endl;

Et vu que ta question est ambiguë, si ce que tu souhaites c'est avoir une précision de 3 décimales :
std::cout << fixed << setprecision(3) << foobar << std::endl;

Mais bon, j'avoue très franchement que le formatage en C++ laisse à désirer, et il m'arrive de revenir aux bonnes vieilles fonctions ...printf() dans certains cas particuliers.

en faite je parlais niveau déclaration, faut-il faire :
double d=3.4f
ou
double d=2.8

le f c'est pour float
pour double tu mets pas de suffixe.

thx

pareil l'écriture avec un u à la fin c'est pour unsigned ?
 
1u par exemple, j'ai déjà vu ça dans du code ..
 
et la deuxième question c'est pourquoi à t-on besoin de préciser f et u ?

 
Oui.  (En passant, pourquoi ne pas utiliser une reference pour ce genre de questions
simples?  le media me semble mal adapte: ce genre de question donnant l'impression
que tu ne cherches rien par toi-meme et ne donne pas envie de repondre.)
 

 
(En passant, ca c'est une de question que je trouve adaptee a ce media; et si elle n'avait pas
ete la, je n'aurais vraisemblablement pas repondu).
 
Pour etre sur d'appeler la fonction surchargee qu'on desire.  Les cas ou le choix est important
sont relativement rares: a priori si il y a surcharge, le comportement devrait etre assez peu  
differents.  Il y a naturellement le cas des tests et celui des IO ou on veut parfois donner une
representation differente suivant le type pour la meme valeur.
 
Dans le cas de 1.0f, je ne vois guere d'autres cas.  A priori float ne devrait d'ailleurs etre utilise
que pour du stockage en quantite importante.  Les calculs, surtout enchaines, se faisant avec des
doubles ou meme des long doubles (mais la on a un probleme de portabilite, long double etant
parfois implemente de maniere similaire au double, parfois avec un peu plus de precision et aucune
perte de performance, parfois avec beaucoup plus de precision et une perte importante de performance).
 
Pour les unsigned, les regles de promotion dans les calculs et les regles de determination qui font
qu'un litteral soit d'une type signe ou non sont relativement complexes, et on parfois des resultats
surprenant, et parfois dependant de l'implementation.  Par soucis de clarete, de portabilite et  
de correction, on peut donc vouloir specifier qu'un litteral est bien non signe.

ok, c'est assez bon comme réponse

Hm. Ça fait bien deux minutes que je bloque sur ce commentaire, en me demandant si c'est vraiment de la condescendance, ou bien une façon maladroite -à l'écrit- de dire merci.

oui merci quoi . mais, sur le : on a parfois des resultats surprenant, ça m'étonne car on sait très bien qu'en informatique il n'y a rien de surprenant, ou de résultats qui tombent du ciel....

Ouais donc t'as lu qu'en diagonale quoi, dans son texte je ne vois nul part mention d'un quelconque résultat aléatoire.

ué en faite je comprends pas cette partie :
Pour les unsigned, les regles de promotion dans les calculs et les regles de determination qui font
qu'un litteral soit d'une type signe ou non sont relativement complexes, et on parfois des resultats
surprenant

enfin bref,c'est plus un forum débutant, je me suis pas forcément adressé au bon endroit, c'est tout de même fou le manque de forum professionnel francophone concernant la programmation.

Ce qu'il veut dire, c'est que les conversions implicites c'est vite le bordel. En gros le compilateur tentera de déterminer si ton nombre est un long double, un double, un float, un unsigned long, un long, etc. jusqu'au int. Mais des fois il se chie dessus.

Par exemple :

 
T'as qu'à être compétent, tu ne seras pas obligé de poser de telles questions, comme ça.

mais donc là tu m'expliques que le fait d'utiliser 'u' ça emmêle le compilateur  

Ce n'est pas le "u" qui emmêle le compilateur, c'est l'absence de typage explicite sur le "2". Le compilateur essaie de prédire son type, et comme unsigned int est plus "prioritaire" que int, il a promu "2" en unsigned int (à cause  du 1u, oui) et effectue la soustraction sur cette base.

ah ok, intéréssant merci

 
Et ca:
 

 
ce n'est pas une question de debutant -- paresseux ou incapable d'aller
voir dans une reference en prime?
 

 
Aide-toi et le ciel t'aidera.  Qu'est-ce qui t'empeche de lancer un tel
forum?
 

 
Non, comme tu le disais si bien,  
 

 
le compilateur il applique les regles.  C'est le programmeur qui s'est
emmele les pinceaux et qui est surpris de ne pas avoir le resultat qu'il
attendait.  Et un professionnel -- et meme un amateur un peu eclaire --
sait tres bien que ca arrive beaucoup plus souvent qu'on ne l'aimerait des
regles qui ont des effets surprenants quand on les applique dans un autre
contexte que celui pour lequel elles ont ete pensees, ou quand elles
interagissent avec d'autres.

 
bah faut déjà être très inspiré pour trouver la requête google qui te donnera un lien où ça sera
expliqué de manière clair et limpide....Et pour ma part j'ai déjà un gros background en developpement,
je pense pouvoir t'apprendre des choses....Le coup du u à la fin,je n'ai jamais eu de cas où son intérêt
était révélé voilà tout, pour le f idem.
 

Le temps.
 
 

 
Je serais tenté de dire que dans 90% des cas, c'est peut être tout simplement  
qu'elles ont été mal pensées....

mais en tout cas merci pour tes réponses, qui m'ont appris des choses, bien évidemment