Bonjour
Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98
J'ai trouvé un turboc++ "free"
Celui-ci refuse de diviser les constantes
ex:
double a = 5/12 ;
printf( " = % lf",a) résultat = 0.000;
Alors que .........................
double b=5;
double c=12;
double a=b/c;
printf( " = % lf",a); résultat = 0.416667
Par contre si je pose
double a = 5*-12;
le résultat est bien -60.000
Ou serait l'erreur, merci.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Loïc Joly
maioré wrote:
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0;
-- Loïc
maioré wrote:
Bonjour
Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98
J'ai trouvé un turboc++ "free"
Celui-ci refuse de diviser les constantes
ex:
double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division
entière, qui vaut l'entier 0. Puis cet entier est transformé en double
pourêtre stocké dans a.
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0;
-- Loïc
maioré
"Loïc Joly" a écrit dans le message de news: bjmjke$iek$
maioré wrote:
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0; ====== D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon compilateur C pour µC Bonne journée
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de news:
bjmjke$iek$1@news-reader3.wanadoo.fr...
maioré wrote:
Bonjour
Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98
J'ai trouvé un turboc++ "free"
Celui-ci refuse de diviser les constantes
ex:
double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division
entière, qui vaut l'entier 0. Puis cet entier est transformé en double
pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0;
====== D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche
Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon
compilateur C pour µC
Bonne journée
"Loïc Joly" a écrit dans le message de news: bjmjke$iek$
maioré wrote:
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0; ====== D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon compilateur C pour µC Bonne journée
Alexandre
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int. C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
"maioré" a écrit dans le message de news:bjmrb8$v1l$
"Loïc Joly" a écrit dans le message de news:
bjmjke$iek$
maioré wrote:
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0; ====== > D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon compilateur C pour µC Bonne journée
pourtant avec tout compilo C/C++ tu aurais le même comportement : une
constante, par défaut, sans cast ni rien est de type int.
C'est pour ça que
long a = 66000; (sur une machine 16 bits, sinon augmenter un peu)
donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
"maioré" <-----.-----@wanadoo.fr> a écrit dans le message de
news:bjmrb8$v1l$1@news-reader1.wanadoo.fr...
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:
bjmjke$iek$1@news-reader3.wanadoo.fr...
maioré wrote:
Bonjour
Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98
J'ai trouvé un turboc++ "free"
Celui-ci refuse de diviser les constantes
ex:
double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division
entière, qui vaut l'entier 0. Puis cet entier est transformé en double
pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0;
====== > D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche
Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon
compilateur C pour µC
Bonne journée
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int. C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
"maioré" a écrit dans le message de news:bjmrb8$v1l$
"Loïc Joly" a écrit dans le message de news:
bjmjke$iek$
maioré wrote:
Bonjour Le pack B5 C++ acheté pour win 95 ne fonctionne plus avec win 98 J'ai trouvé un turboc++ "free" Celui-ci refuse de diviser les constantes ex: double a = 5/12 ;
Tu divises l'entier 5 par l'entier 12, donc tu fais une division entière, qui vaut l'entier 0. Puis cet entier est transformé en double pourêtre stocké dans a.
Ecris plutôt : double a = 5.0/12.0; ====== > D'accord ou il faut les forcer avec (double)5 / (double)12.
Merci Loic ça marche Ma foi, Je ne me rappelle pas avoir eu ce cas avec BC5 C++ ni avec mon compilateur C pour µC Bonne journée
Michel Michaud
Dans news:3f67564d$0$27574$,
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int. C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans problème en long. Si ça n'entre pas, 66000 est alors un long, même si tu n'écris pas le L. En fait, le L c'est vraiment utile seulement si tu veux appeler une fonction surchargée avec une valeur qui entre autant dans un int que dans un long.
(En C, le L était nécessaire pour appeler correctement les fonctions sans prototype ou avec nombre variables de paramètres. Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop grande pour un long, mais entre dans un unsigned long, elle sera de ce type, même si on n'écrit pas le suffixe U.
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:3f67564d$0$27574$626a54ce@news.free.fr,
pourtant avec tout compilo C/C++ tu aurais le même comportement :
une constante, par défaut, sans cast ni rien est de type int.
C'est pour ça que
long a = 66000; (sur une machine 16 bits, sinon augmenter un peu)
donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans
problème en long. Si ça n'entre pas, 66000 est alors un long,
même si tu n'écris pas le L. En fait, le L c'est vraiment
utile seulement si tu veux appeler une fonction surchargée
avec une valeur qui entre autant dans un int que dans un long.
(En C, le L était nécessaire pour appeler correctement les
fonctions sans prototype ou avec nombre variables de paramètres.
Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop
grande pour un long, mais entre dans un unsigned long, elle sera
de ce type, même si on n'écrit pas le suffixe U.
Heureusement C et C++ n'offrent pas vraiment de surprise avec les
constantes numériques écrites normalement... Par contre, si on les
écrit en hexadécimal inutilement, là c'est plus subtil !
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int. C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans problème en long. Si ça n'entre pas, 66000 est alors un long, même si tu n'écris pas le L. En fait, le L c'est vraiment utile seulement si tu veux appeler une fonction surchargée avec une valeur qui entre autant dans un int que dans un long.
(En C, le L était nécessaire pour appeler correctement les fonctions sans prototype ou avec nombre variables de paramètres. Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop grande pour un long, mais entre dans un unsigned long, elle sera de ce type, même si on n'écrit pas le suffixe U.
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
drkm
"Michel Michaud" writes:
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
Quelle est la différence ?
--drkm
"Michel Michaud" <mm@gdzid.com> writes:
Heureusement C et C++ n'offrent pas vraiment de surprise avec les
constantes numériques écrites normalement... Par contre, si on les
écrit en hexadécimal inutilement, là c'est plus subtil !
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
Quelle est la différence ?
--drkm
Gabriel Dos Reis
writes:
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il contient | une constante entière dont la valeur ne passe pas dans un des types | permis. Ce qui semble une contradiction avec le comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le cas où tu as un fonctionnement indéfini.
-- Gaby
kanze@gabi-soft.fr writes:
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il contient
| une constante entière dont la valeur ne passe pas dans un des types
| permis. Ce qui semble une contradiction avec le comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le
cas où tu as un fonctionnement indéfini.
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il contient | une constante entière dont la valeur ne passe pas dans un des types | permis. Ce qui semble une contradiction avec le comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le cas où tu as un fonctionnement indéfini.
-- Gaby
Michel Michaud
Dans news:,
"Michel Michaud" wrote in message news:<rQN9b.5962$...
Dans news:3f67564d$0$27574$,
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int.
C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans problème en long. Si ça n'entre pas, 66000 est alors un long, même si tu n'écris pas le L. En fait, le L c'est vraiment utile seulement si tu veux appeler une fonction surchargée avec une valeur qui entre autant dans un int que dans un long.
Ce qui ne change rien au problème -- si tu utilises 66000L pour
Désolé, je ne me souviens plus du début de la conversation : quel était ce problème ?
initialiser un int de 16 bits, tu n'aurais pas ce que tu y attends.
Qu'on mette le L ou non, ça ne changera rien.
Personnellement, je m'attendrais à ce qu'un bon compilateur émet un avertissement.
Si la valeur est trop grosse pour initialiser la constante d'un certain type, j'aime aussi (mais là on parlait d'un long et de 66000... ce n'est pas trop gros, L ou pas).
Quant à l'utilité du L, il y en a une très important que tu as oubliée : il indique à la personne qui lit le code que tu savais ce que tu faisais.
Tu crois ? Elle voulait faire quoi ? Je ne vois pas ce qui te fait dire qu'elle sait ce qu'elle fait si elle écrit long n= 66000L; au lieu de long n= 66000;. Si 66000 ne rentre pas dans un long, 66000L n'entre pas non plus. 66000 entre évidemment, mais supposons qu'on écrive 66000000000... L ou pas, je ne vois pas la différence au niveau de « la personne sait ce qu'elle fait ».
(En C, le L était nécessaire pour appeler correctement les fonctions sans prototype ou avec nombre variables de paramètres. Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop grande pour un long, mais entre dans un unsigned long, elle sera de ce type, même si on n'écrit pas le suffixe U.
Ce n'est pas ce que dit §2.13.1/2. (Et j'avoue, ça m'a étonné, parce que je croyais la même chose. Je me démande d'où nous l'avons.) Si la constante n'entre pas dans un long int, c'est un comportement indéfini. Donc, si tu écris une définition du genre : int const i = 3000000000 ; gare à ton disque.
Wow ! Surprise ! C'est pourtant ce que je pensais (de C ?) et ce que dit même Stroustrup lui-même : « if it is decimal and has no suffix, it has the first of these types in which its value can be represented : int, long int, unsigned long int. ». Je viens d'écrire à BS...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans news:d6652001.0309170330.409397aa@posting.google.com,
"Michel Michaud" <mm@gdzid.com> wrote in message
news:<rQN9b.5962$hF3.685155@news20.bellglobal.com>...
Dans news:3f67564d$0$27574$626a54ce@news.free.fr,
pourtant avec tout compilo C/C++ tu aurais le même comportement :
une constante, par défaut, sans cast ni rien est de type int.
C'est pour ça que
long a = 66000; (sur une machine 16 bits, sinon augmenter un peu)
donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans
problème en long. Si ça n'entre pas, 66000 est alors un long, même
si tu n'écris pas le L. En fait, le L c'est vraiment utile
seulement si tu veux appeler une fonction surchargée avec une
valeur qui entre autant dans un int que dans un long.
Ce qui ne change rien au problème -- si tu utilises 66000L pour
Désolé, je ne me souviens plus du début de la conversation :
quel était ce problème ?
initialiser un int de 16 bits, tu n'aurais pas ce que tu y attends.
Qu'on mette le L ou non, ça ne changera rien.
Personnellement, je m'attendrais à ce qu'un bon compilateur émet un
avertissement.
Si la valeur est trop grosse pour initialiser la constante d'un
certain type, j'aime aussi (mais là on parlait d'un long et de
66000... ce n'est pas trop gros, L ou pas).
Quant à l'utilité du L, il y en a une très important que tu as
oubliée : il indique à la personne qui lit le code que tu savais ce
que tu faisais.
Tu crois ? Elle voulait faire quoi ? Je ne vois pas ce qui te fait
dire qu'elle sait ce qu'elle fait si elle écrit long n= 66000L;
au lieu de long n= 66000;. Si 66000 ne rentre pas dans un long,
66000L n'entre pas non plus. 66000 entre évidemment, mais supposons
qu'on écrive 66000000000... L ou pas, je ne vois pas la différence
au niveau de « la personne sait ce qu'elle fait ».
(En C, le L était nécessaire pour appeler correctement les
fonctions sans prototype ou avec nombre variables de paramètres.
Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop
grande pour un long, mais entre dans un unsigned long, elle sera
de ce type, même si on n'écrit pas le suffixe U.
Ce n'est pas ce que dit §2.13.1/2. (Et j'avoue, ça m'a étonné,
parce que je croyais la même chose. Je me démande d'où nous
l'avons.) Si la constante n'entre pas dans un long int, c'est un
comportement indéfini. Donc, si tu écris une définition du genre :
int const i = 3000000000 ;
gare à ton disque.
Wow ! Surprise ! C'est pourtant ce que je pensais (de C ?) et
ce que dit même Stroustrup lui-même : « if it is decimal and has
no suffix, it has the first of these types in which its value
can be represented : int, long int, unsigned long int. ». Je
viens d'écrire à BS...
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Michel Michaud" wrote in message news:<rQN9b.5962$...
Dans news:3f67564d$0$27574$,
pourtant avec tout compilo C/C++ tu aurais le même comportement : une constante, par défaut, sans cast ni rien est de type int.
C'est pour ça que long a = 66000; (sur une machine 16 bits, sinon augmenter un peu) donne un résultat "étrange" et qu'il faut écrire long a= 66000L;
Non, si 66000 entre dans un int, ce sera un int convertible sans problème en long. Si ça n'entre pas, 66000 est alors un long, même si tu n'écris pas le L. En fait, le L c'est vraiment utile seulement si tu veux appeler une fonction surchargée avec une valeur qui entre autant dans un int que dans un long.
Ce qui ne change rien au problème -- si tu utilises 66000L pour
Désolé, je ne me souviens plus du début de la conversation : quel était ce problème ?
initialiser un int de 16 bits, tu n'aurais pas ce que tu y attends.
Qu'on mette le L ou non, ça ne changera rien.
Personnellement, je m'attendrais à ce qu'un bon compilateur émet un avertissement.
Si la valeur est trop grosse pour initialiser la constante d'un certain type, j'aime aussi (mais là on parlait d'un long et de 66000... ce n'est pas trop gros, L ou pas).
Quant à l'utilité du L, il y en a une très important que tu as oubliée : il indique à la personne qui lit le code que tu savais ce que tu faisais.
Tu crois ? Elle voulait faire quoi ? Je ne vois pas ce qui te fait dire qu'elle sait ce qu'elle fait si elle écrit long n= 66000L; au lieu de long n= 66000;. Si 66000 ne rentre pas dans un long, 66000L n'entre pas non plus. 66000 entre évidemment, mais supposons qu'on écrive 66000000000... L ou pas, je ne vois pas la différence au niveau de « la personne sait ce qu'elle fait ».
(En C, le L était nécessaire pour appeler correctement les fonctions sans prototype ou avec nombre variables de paramètres. Ce deuxième cas est possible aussi en C++ en fait.)
Similairement, si la valeur d'une constante littérale est trop grande pour un long, mais entre dans un unsigned long, elle sera de ce type, même si on n'écrit pas le suffixe U.
Ce n'est pas ce que dit §2.13.1/2. (Et j'avoue, ça m'a étonné, parce que je croyais la même chose. Je me démande d'où nous l'avons.) Si la constante n'entre pas dans un long int, c'est un comportement indéfini. Donc, si tu écris une définition du genre : int const i = 3000000000 ; gare à ton disque.
Wow ! Surprise ! C'est pourtant ce que je pensais (de C ?) et ce que dit même Stroustrup lui-même : « if it is decimal and has no suffix, it has the first of these types in which its value can be represented : int, long int, unsigned long int. ». Je viens d'écrire à BS...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans news:,
"Michel Michaud" writes:
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
Quelle est la différence ?
Ça peut passer par les unsigned int... 65000 est long si les int ont 16 bits, mais 0xFDE8 -- qui est 65000 en hexa -- est plutôt unsigned int. Et l'emploi de nombres de type unsigned est toujours subtil... -- Michel Michaud
http://www.gdzid.com
Dans news:wkwuc8jats.fsf@fgeorges.org,
"Michel Michaud" <mm@gdzid.com> writes:
Heureusement C et C++ n'offrent pas vraiment de surprise avec les
constantes numériques écrites normalement... Par contre, si on les
écrit en hexadécimal inutilement, là c'est plus subtil !
Quelle est la différence ?
Ça peut passer par les unsigned int... 65000 est long si les
int ont 16 bits, mais 0xFDE8 -- qui est 65000 en hexa -- est
plutôt unsigned int. Et l'emploi de nombres de type unsigned
est toujours subtil...
--
Michel Michaud
michel.michaud@cstjean.qc.ca
http://www.gdzid.com
Heureusement C et C++ n'offrent pas vraiment de surprise avec les constantes numériques écrites normalement... Par contre, si on les écrit en hexadécimal inutilement, là c'est plus subtil !
Quelle est la différence ?
Ça peut passer par les unsigned int... 65000 est long si les int ont 16 bits, mais 0xFDE8 -- qui est 65000 en hexa -- est plutôt unsigned int. Et l'emploi de nombres de type unsigned est toujours subtil... -- Michel Michaud
http://www.gdzid.com
kanze
Gabriel Dos Reis wrote in message news:...
writes:
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il | contient une constante entière dont la valeur ne passe pas dans un | des types permis. Ce qui semble une contradiction avec le | comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le cas où tu as un fonctionnement indéfini.
Sauf que par définition et par tradition, les mots « undefined behavior » signifie une absence totale de limitations.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Gabriel Dos Reis <gdr@integrable-solutions.net> wrote in message
news:<m365jrd4mg.fsf@uniton.integrable-solutions.net>...
kanze@gabi-soft.fr writes:
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il
| contient une constante entière dont la valeur ne passe pas dans un
| des types permis. Ce qui semble une contradiction avec le
| comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le
cas où tu as un fonctionnement indéfini.
Sauf que par définition et par tradition, les mots « undefined
behavior » signifie une absence totale de limitations.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
| (En revanche, §2.13.1/3 dit que le programme est mal-formé s'il | contient une constante entière dont la valeur ne passe pas dans un | des types permis. Ce qui semble une contradiction avec le | comportement indéfini.)
au lieu de rentrer en conflit, je crois qu'il délimite un peu mieux le cas où tu as un fonctionnement indéfini.
Sauf que par définition et par tradition, les mots « undefined behavior » signifie une absence totale de limitations.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
