Quand je demande un double en C++, il occupe combien d'octets ?
Quel est l'intervalle des valeurs autorisée ?
En java, le langage définit tout ça.
Mais en C++, qui décide ?
La plateforme (32/64bits) ? Le compilateur ?, le couple plateforme /compilateur ?
Avec gcc, sur un PC 32, je trouve l'info où ?
Merci pour vos lumières.
Forum Programmation.c++ Un double, sec, svp.
13
jan.
2005
# test it
Posté par schyzomarijks . Évalué à 4.
#include using namespace std; int main(int argc, char **argv ) { cout << sizeof(double) << endl; return 0; }(A peu près) Pour moi, c'est le compilo qui décide en s'appuyant sur la plateforme cible[^] # Re: test it
Posté par Antoine Reilles (site web personnel) . Évalué à 3.
qu'il faut lire
# Dans la spec
Posté par Epsos . Évalué à 3.
8° paragraphe
C'est vraiment pas clair ... :-)
Grosso modo, sur des 32 bits, un float sera sur 4 octets, et un double sur 8.
[^] # Re: Dans la spec
Posté par locnet . Évalué à 2.
Rien de très clair effectivement.
Mais je veux bien te croire pour 4 et 8 octets.
[^] # Re: Dans la spec
Posté par Epsos . Évalué à 3.
#include <limits>
numeric_limits<float>::min();
numeric_limits<float>::max();
numeric_limits<double>::min();
numeric_limits<double>::max();
...
# Ça n'est pas précisé par la norme ...
Posté par Florent C. . Évalué à 2.
La taille des types dépend essentiellement de ta machine, de ton OS, et de ton compilateur.
Par contre il y a des règles :
1/ sizeof (char) == 1
2/ sizeof (char) <= sizeof (short) <= sizeof (int) <= sizeof (unsigned)
3/ un float est représenté selon la normae IEEE 755, et un double c'est la même chose, mais avec une précision double (donc deux fois plus d'octets)
Maintenant, si tu veux absolument savoir quelle taille il fait, tu dois le faire au runtime grâce à sizeof ...
[^] # Re: Ça n'est pas précisé par la norme ...
Posté par Florent C. . Évalué à 1.
Remplacer sizeof (unsigned) par sizeof (long).
Evidemment sizeof (unsigned) == sizeof (int).
# C'est un probleme notoire
Posté par Philippe F (site web personnel) . Évalué à 2.
Leur taille est donc dependante du compilateur et de la plateforme. Autant dire que c'est le bordel.
Le seul moyen fiable de savoir, c'est l'operateur sizeof. Ca fait partie des choses qui sont testees dans les scripts configure. Normalement, tu dois recuperer qqpart des macros MAX_INT, MAX_DOUBLE et autres pour t'aider.
[^] # Re: C'est un probleme notoire
Posté par Florent C. . Évalué à 3.
Non, c'est ainsi dans un souci de portabilité. Un programme C n'est pas prévu pour tourner dans une machine virtuelle, mais sur n'importe quelle architecture (s'il est programmé de manière portable, bien sûr).
Et comme la portabilité est la première raison d'être du langage C, c'est très bien comme ça.
Autre chose. sizeof renvoie une taille en byte. Vous me direz, "oui, et alors ?" ... Et bien le mot "byte" en anglais ne signifie pas "octet", mais multiplet. Un octet est un multiplet de 8 bits. En anglais, octet se dit octet. Et sur certaines machines, les bytes font 7 bits. Encore une fois, merci aux concepteurs du langage C de nous avoir simplifié la portabilité : on compte en bytes, et ça marche sur n'importe quelle machine.
[^] # Re: C'est un probleme notoire
Posté par locnet . Évalué à 2.
Non, c'est ainsi dans un souci de portabilité. Un programme C n'est pas prévu pour tourner dans une machine virtuelle, mais sur n'importe quelle architecture (s'il est programmé de manière portable, bien sûr).
Et comme la portabilité est la première raison d'être du langage C, c'est très bien comme ça.
...
ça marche sur n'importe quelle machine.
Ok, mon programme :
- va se compiler sur toutes les plateformes (même dans 50 ans, sur des machines 1024 bits),
- va s'exécuter sur toutes les plateformes
- va potentiellement donner des résultats différents.
<mon avis troll=on>
Je préfère la portabilité java. Si ca compile ( càd si le compilateur existe), ça donne le même résultat partout.
Même si pour exploiter les architectures 1024 bits, une nouvelle version du langage sera nécessaire pour introduire les archi-long-double
</mon avis>
[^] # Re: C'est un probleme notoire
Posté par Florent C. . Évalué à 1.
Très bien, c'est ton droit. Je ne faisais que citer le pourquoi du comment de la taille des types dans le langage C.
[^] # Re: C'est un probleme notoire
Posté par Philippe F (site web personnel) . Évalué à 4.
Tu dis des conneries. Ca ne fait que diminuer la portabilite. Tout ce qui n'est pas specifie conduit a des implementations diverses qui conduisent a de la non portabilite. C'est ainsi parce que K&R voulait laisser la possbilite au langage de tourner sur des plus grosses implementations. Ils n'ont pas realise tous les problemes de portabilite que ca entrainait.
> Et comme la portabilité est la première raison d'être du langage C,
Le langage C a ete developpe pour developper le premier unix. C'est sa premiere et son unique raison d'etre. Il avait l'avantage d'etre beaucoup plus portable que le code developpe en assembleur.
Toutes les autres conclusions que tu fais sont fantaisistes. Notamment, Java ou Ada est bien plus portable jsutement parce que ce genre de chose est specifie avec precision.
La difference, c'est que ces langages ont ete concus des le depart dans un souci de portabilite.
[^] # Re: C'est un probleme notoire
Posté par Florent C. . Évalué à 2.
Le langage C a été développé pour ne pas avoir à réécrire UNIX en assembleur pour toutes les machines sur lesquelles UNIX devait tourner. Donc, sa première raison d'être, c'est bien la portabilité.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.