signed int valeur; signed int valeur; que dit la norme au sujet de ce type ?
j'ai cherché un petit peu, je n'ai pas trouvé. y'a une contre indication ?
je pense que le type 'int' est, sauf indication contraire, "signed"
qui a déja vu : signed int main() ???
Mickaël Wolff
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur. <http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
FAQ très intéressante : <http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Non_002dbugs.html>
qui a déja vu : signed int main() ???
Pourquoi pas ? Mais dans ce cas, je mettrais signed main () pour porter à confusion :p
Bref, comme toujours, tu as fait le choix de l'a priori, comme nous le faisons tous ;) Les programmeurs sont incorrigibles. -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur.
<http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
FAQ très intéressante :
<http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Non_002dbugs.html>
qui a déja vu : signed int main() ???
Pourquoi pas ? Mais dans ce cas, je mettrais signed main () pour
porter à confusion :p
Bref, comme toujours, tu as fait le choix de l'a priori, comme nous le
faisons tous ;) Les programmeurs sont incorrigibles.
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur. <http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
FAQ très intéressante : <http://developer.apple.com/documentation/developertools/gcc-4.0.1/gcc/Non_002dbugs.html>
qui a déja vu : signed int main() ???
Pourquoi pas ? Mais dans ce cas, je mettrais signed main () pour porter à confusion :p
Bref, comme toujours, tu as fait le choix de l'a priori, comme nous le faisons tous ;) Les programmeurs sont incorrigibles. -- Mickaël Wolff aka Lupus Michaelis http://lupusmic.org
gl
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur. <http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur.
<http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.
je pense que le type 'int' est, sauf indication contraire, "signed"
Ça dépend de la machine, et du choix d'implémentation du compilateur. <http://www.network-theory.co.uk/docs/gccintro/gccintro_71.html>
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
Mickaël Wolff
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
In article <46f4fa9e$0$3550$, Mickaël Wolff wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume rapide des regles de base de portabilite des types entiers:
- les types standards int, short, long sont toujours signes, quel que soit le compilateur, quelle que soit la machine. - donc int == signed int, short == signed short, long == signed long. - char est un cas particulier. Selon les implementations, char peut etre signe, ou non signe. Il faut preciser si on veut explicitement des signed char, ou des unsigned char. - je ne detaillerai pas les wchar_t (qui sont un typedef en C et un type natif en C++. Il suffit ici de savoir qu'ils existent.
- L'implementation des types signes en C laisse enormement de latitude a l'implementeur. Il est juste dit que les short doivent pouvoir representer l'intervalle -32767,+32767, les int pareils, et les longs montent jusqu'a 2^31. Il n'y a guere de contrainte de representation (meme si on s'oriente vers de la representation en complement a 2, ou complement a 1 de facon explicite). La norme ne dit rien sur ce qui se passe en cas de debordement de capacite. - le type char fait au moins 8 bits. Il peut faire plus, la constante CHAR_BIT permet de savoir ou on en est. - par definition, sizeof(char) == 1. - les types unsigned sont plus precis. Ils se comportent precisement comme doit se comporter de l'arithmetique modulaire dans Z/2^n Z, pour une valeur adequate de n.
- une implementation peut contenir des types entiers supplementaires, eventuellement plus grands. - C99 standardise long long, ainsi que tous les intN_t et int_leastN_t et consorts. - Si l'implementation dispose de types entiers pour une taille donnee, elle DOIT definir intN_t. - Une implementation DOIT definir une serie de intleastN_t raisonnable pour pretendre etre completement standard (de memoire, 16, 32, 64... a verifier dans la norme).
In article <46f4fa9e$0$3550$426a34cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume
rapide des regles de base de portabilite des types entiers:
- les types standards int, short, long sont toujours signes, quel que soit
le compilateur, quelle que soit la machine.
- donc int == signed int, short == signed short, long == signed long.
- char est un cas particulier. Selon les implementations, char peut etre
signe, ou non signe. Il faut preciser si on veut explicitement des
signed char, ou des unsigned char.
- je ne detaillerai pas les wchar_t (qui sont un typedef en C et un type
natif en C++. Il suffit ici de savoir qu'ils existent.
- L'implementation des types signes en C laisse enormement de latitude a
l'implementeur. Il est juste dit que les short doivent pouvoir representer
l'intervalle -32767,+32767, les int pareils, et les longs montent jusqu'a
2^31. Il n'y a guere de contrainte de representation (meme si on s'oriente
vers de la representation en complement a 2, ou complement a 1 de
facon explicite). La norme ne dit rien sur ce qui se passe en cas de
debordement de capacite.
- le type char fait au moins 8 bits. Il peut faire plus, la constante
CHAR_BIT permet de savoir ou on en est.
- par definition, sizeof(char) == 1.
- les types unsigned sont plus precis. Ils se comportent precisement comme
doit se comporter de l'arithmetique modulaire dans Z/2^n Z, pour une valeur
adequate de n.
- une implementation peut contenir des types entiers supplementaires,
eventuellement plus grands.
- C99 standardise long long, ainsi que tous les intN_t et int_leastN_t et
consorts.
- Si l'implementation dispose de types entiers pour une taille donnee,
elle DOIT definir intN_t.
- Une implementation DOIT definir une serie de intleastN_t raisonnable
pour pretendre etre completement standard (de memoire, 16, 32, 64... a
verifier dans la norme).
In article <46f4fa9e$0$3550$, Mickaël Wolff wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume rapide des regles de base de portabilite des types entiers:
- les types standards int, short, long sont toujours signes, quel que soit le compilateur, quelle que soit la machine. - donc int == signed int, short == signed short, long == signed long. - char est un cas particulier. Selon les implementations, char peut etre signe, ou non signe. Il faut preciser si on veut explicitement des signed char, ou des unsigned char. - je ne detaillerai pas les wchar_t (qui sont un typedef en C et un type natif en C++. Il suffit ici de savoir qu'ils existent.
- L'implementation des types signes en C laisse enormement de latitude a l'implementeur. Il est juste dit que les short doivent pouvoir representer l'intervalle -32767,+32767, les int pareils, et les longs montent jusqu'a 2^31. Il n'y a guere de contrainte de representation (meme si on s'oriente vers de la representation en complement a 2, ou complement a 1 de facon explicite). La norme ne dit rien sur ce qui se passe en cas de debordement de capacite. - le type char fait au moins 8 bits. Il peut faire plus, la constante CHAR_BIT permet de savoir ou on en est. - par definition, sizeof(char) == 1. - les types unsigned sont plus precis. Ils se comportent precisement comme doit se comporter de l'arithmetique modulaire dans Z/2^n Z, pour une valeur adequate de n.
- une implementation peut contenir des types entiers supplementaires, eventuellement plus grands. - C99 standardise long long, ainsi que tous les intN_t et int_leastN_t et consorts. - Si l'implementation dispose de types entiers pour une taille donnee, elle DOIT definir intN_t. - Une implementation DOIT definir une serie de intleastN_t raisonnable pour pretendre etre completement standard (de memoire, 16, 32, 64... a verifier dans la norme).
gl
C'est la même chose, ce sont des entiers tout les deux.
Ce sont des types entiers, mais ca s'arrete la, ce n'est pas la meme chose
Il y a un qui est juste de taille déterminée.
Ah bon ? Par convention sizeof(char) vaut 1, le char etant la reference des tailles memoires. Mais il n'y a pas de taille imposee pour char ni pour int (seulement des plages minimales de valeur).
Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Ben justement non, je ne vois rien dans l'article qui generalise ce fait a tous les types entiers.
C'est la même chose, ce sont des entiers tout les deux.
Ce sont des types entiers, mais ca s'arrete la, ce n'est pas la meme chose
Il y a un qui est juste de taille déterminée.
Ah bon ? Par convention sizeof(char) vaut 1, le char etant la reference
des tailles memoires.
Mais il n'y a pas de taille imposee pour char ni pour int (seulement des
plages minimales de valeur).
Mais en lisant bien une seconde fois, tu verras que le char n'est traité
qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.
Ben justement non, je ne vois rien dans l'article qui generalise ce fait
a tous les types entiers.
C'est la même chose, ce sont des entiers tout les deux.
Ce sont des types entiers, mais ca s'arrete la, ce n'est pas la meme chose
Il y a un qui est juste de taille déterminée.
Ah bon ? Par convention sizeof(char) vaut 1, le char etant la reference des tailles memoires. Mais il n'y a pas de taille imposee pour char ni pour int (seulement des plages minimales de valeur).
Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Ben justement non, je ne vois rien dans l'article qui generalise ce fait a tous les types entiers.
Jean-Marc Bourguet
(Marc Espie) writes:
In article <46f4fa9e$0$3550$, Mickaël Wolff wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume rapide des regles de base de portabilite des types entiers:
Tu oublies que les bitfields (pour Mickael, i dans struct s { int i:5; }; et *pas* tous les objets entiers) sont aussi un cas particulier où il faut préciser le signe si ça a de l'importance.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
espie@lain.home (Marc Espie) writes:
In article <46f4fa9e$0$3550$426a34cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe
ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui
est juste de taille déterminée. Mais en lisant bien une seconde fois, tu
verras que le char n'est traité qu'en cas particulier, et que l'auteur
dit que c'est généralisable à tout les bitfields. À savoir les entiers
char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume
rapide des regles de base de portabilite des types entiers:
Tu oublies que les bitfields (pour Mickael, i dans struct s { int i:5; };
et *pas* tous les objets entiers) sont aussi un cas particulier où il faut
préciser le signe si ça a de l'importance.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
In article <46f4fa9e$0$3550$, Mickaël Wolff wrote:
Le lien fournit traite du cas de char qui peut effectivement etre signe ou non, pas du cas de int.
C'est la même chose, ce sont des entiers tout les deux. Il y a un qui est juste de taille déterminée. Mais en lisant bien une seconde fois, tu verras que le char n'est traité qu'en cas particulier, et que l'auteur dit que c'est généralisable à tout les bitfields. À savoir les entiers char, int et long.
Comme ce que tu racontes n'est pas clair du tout, un petit resume rapide des regles de base de portabilite des types entiers:
Tu oublies que les bitfields (pour Mickael, i dans struct s { int i:5; }; et *pas* tous les objets entiers) sont aussi un cas particulier où il faut préciser le signe si ça a de l'importance.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
