Dans mon livre, il me demande ceci à écrire, mais il ne me donne pas la
solution donc je demande ici :
"Écrivez un programme qui reçoit trois entiers entrés au clavier et
affiche la somme, la moyenne, le produit, le plus petit et le plus grand
de ces nombres."
Bref, j'ai beau essayé, mais mon code, j'en reste bloqué là :( ..
en plus de toutes les (très pertinentes) remarques des autres posts, notes bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Extrait de la norme :
2.5 Alternative tokens 1 Alternative token representations are provided for some operators and punctuators16). 2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token,except for its spelling17). The set of alternative tokens is defined in Table 2.
Table 2alternative tokens _____________________________________________________________ alternative primary alternative primary alternative primary _____________________________________________________________ <% { and && and_eq & %> } bitor | or_eq | <: [ or || xor_eq ^ :> ] xor ^ not ! %: # compl ~ not_eq ! %:%: ## bitand & _____________________________________________________________
-- Loïc
Alexandre wrote:
bonjour,
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts, notes
bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Extrait de la norme :
2.5 Alternative tokens
1 Alternative token representations are provided for some operators and
punctuators16).
2 In all respects of the language, each alternative token behaves the
same, respectively, as its primary token,except for its spelling17). The
set of alternative tokens is defined in Table 2.
Table 2alternative tokens
_____________________________________________________________
alternative primary alternative primary alternative primary
_____________________________________________________________
<% { and && and_eq & %> } bitor | or_eq | <: [ or || xor_eq ^ :> ] xor ^ not !
%: # compl ~ not_eq ! %:%: ## bitand &
_____________________________________________________________
en plus de toutes les (très pertinentes) remarques des autres posts, notes bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Extrait de la norme :
2.5 Alternative tokens 1 Alternative token representations are provided for some operators and punctuators16). 2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token,except for its spelling17). The set of alternative tokens is defined in Table 2.
Table 2alternative tokens _____________________________________________________________ alternative primary alternative primary alternative primary _____________________________________________________________ <% { and && and_eq & %> } bitor | or_eq | <: [ or || xor_eq ^ :> ] xor ^ not ! %: # compl ~ not_eq ! %:%: ## bitand & _____________________________________________________________
-- Loïc
Vincent Lascaux
v.sort(); minVal = v[0];
Pas std::min_element() ?
Je considère que sort fait partie de ce qui est vraiment utile, alors que je vois plus min_element comme une curiosité. Pour ne pas noyer un débutant, je préfère ne lui montrer que la partie emmergée de la STL, plutôt que de le noyer en lui demandant de regarder ce qu'il y a en dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même moche (même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
-- Vincent
v.sort();
minVal = v[0];
Pas std::min_element() ?
Je considère que sort fait partie de ce qui est vraiment utile, alors
que je vois plus min_element comme une curiosité. Pour ne pas noyer un
débutant, je préfère ne lui montrer que la partie emmergée de la STL,
plutôt que de le noyer en lui demandant de regarder ce qu'il y a en
dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même
moche (même si ca veut evidemment rien dire cette complexité puisqu'on sait
qu'on aura toujours 3 et seulement 3 élements).
Je considère que sort fait partie de ce qui est vraiment utile, alors que je vois plus min_element comme une curiosité. Pour ne pas noyer un débutant, je préfère ne lui montrer que la partie emmergée de la STL, plutôt que de le noyer en lui demandant de regarder ce qu'il y a en dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même moche (même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
-- Vincent
Loïc Joly
Vincent Lascaux wrote:
v.sort(); minVal = v[0];
Pas std::min_element() ?
Je considère que sort fait partie de ce qui est vraiment utile, alors que je vois plus min_element comme une curiosité. Pour ne pas noyer un débutant, je préfère ne lui montrer que la partie emmergée de la STL, plutôt que de le noyer en lui demandant de regarder ce qu'il y a en dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même moche
Oui, et ? En terme de performances, mettre dans un vector et boucler alors qu'on sait très bien qu'il n'y a que trois éléments, c'est moche aussi par rapport à ces critères. Dans le cadre d'un apprentissage, il me semble important de privilégier l'aspect progressif par rapport à l'aspect élégant, quand les deux sont en désacord.
Je n'ai par exemple jamais vu en premier programme l'affichage de "Bonjour à tous" à l'écran. Comme c'est trop complexe, les auteurs, même français, préfères afficher "Hello world!". Pourtant un message francisé serait bien moins moche.
(même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant et un min_element et un max_element, la méthode avec sort perd en terme de perfs dès un vector de taille 1.
-- Loïc
Vincent Lascaux wrote:
v.sort();
minVal = v[0];
Pas std::min_element() ?
Je considère que sort fait partie de ce qui est vraiment utile, alors
que je vois plus min_element comme une curiosité. Pour ne pas noyer un
débutant, je préfère ne lui montrer que la partie emmergée de la STL,
plutôt que de le noyer en lui demandant de regarder ce qu'il y a en
dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même
moche
Oui, et ?
En terme de performances, mettre dans un vector et boucler alors qu'on
sait très bien qu'il n'y a que trois éléments, c'est moche aussi par
rapport à ces critères. Dans le cadre d'un apprentissage, il me semble
important de privilégier l'aspect progressif par rapport à l'aspect
élégant, quand les deux sont en désacord.
Je n'ai par exemple jamais vu en premier programme l'affichage de
"Bonjour à tous" à l'écran. Comme c'est trop complexe, les auteurs, même
français, préfères afficher "Hello world!". Pourtant un message francisé
serait bien moins moche.
(même si ca veut evidemment rien dire cette complexité puisqu'on sait
qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant
et un min_element et un max_element, la méthode avec sort perd en terme
de perfs dès un vector de taille 1.
Je considère que sort fait partie de ce qui est vraiment utile, alors que je vois plus min_element comme une curiosité. Pour ne pas noyer un débutant, je préfère ne lui montrer que la partie emmergée de la STL, plutôt que de le noyer en lui demandant de regarder ce qu'il y a en dessous.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même moche
Oui, et ? En terme de performances, mettre dans un vector et boucler alors qu'on sait très bien qu'il n'y a que trois éléments, c'est moche aussi par rapport à ces critères. Dans le cadre d'un apprentissage, il me semble important de privilégier l'aspect progressif par rapport à l'aspect élégant, quand les deux sont en désacord.
Je n'ai par exemple jamais vu en premier programme l'affichage de "Bonjour à tous" à l'écran. Comme c'est trop complexe, les auteurs, même français, préfères afficher "Hello world!". Pourtant un message francisé serait bien moins moche.
(même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant et un min_element et un max_element, la méthode avec sort perd en terme de perfs dès un vector de taille 1.
-- Loïc
Vincent Lascaux
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même
moche
Oui, et ? En terme de performances, mettre dans un vector et boucler alors qu'on sait très bien qu'il n'y a que trois éléments, c'est moche aussi par rapport à ces critères. Dans le cadre d'un apprentissage, il me semble important de privilégier l'aspect progressif par rapport à l'aspect élégant, quand les deux sont en désacord.
Je pense que quelqu'un qui apprend le C++ peut avoir des connaissances en algorithmie, et ca peut lui sembler étrange, le déranger, qu'on trie un tableau pour récuperer le plus petit / grand élement. Si j'étais prof, je ne prendrais par example pas le risque que quelqu'un souleve ce point (mais je suis pas prof). Je suis pas convaincu que std::min_element soit vraiment plus compliqué à comprendre que std::sort (moins util peut etre, mais j'espere que l'esprit de l'eleve ne sera pas embrouillé par une ligne qui dit "min_element(tableau)". C'est assez clair pour ne pas demander plus d'explication).
(même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant et un min_element et un max_element, la méthode avec sort perd en terme de perfs dès un vector de taille 1.
Ca ne m'étonne pas vraiment. Ce que je voulais dire c'est que d'un point de vue algorithmique, on peut pas vraiment parler de complexité si on sait qu'on utilise 3 et seulement 3 élements.
-- Vincent
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand
même
moche
Oui, et ?
En terme de performances, mettre dans un vector et boucler alors qu'on
sait très bien qu'il n'y a que trois éléments, c'est moche aussi par
rapport à ces critères. Dans le cadre d'un apprentissage, il me semble
important de privilégier l'aspect progressif par rapport à l'aspect
élégant, quand les deux sont en désacord.
Je pense que quelqu'un qui apprend le C++ peut avoir des connaissances en
algorithmie, et ca peut lui sembler étrange, le déranger, qu'on trie un
tableau pour récuperer le plus petit / grand élement.
Si j'étais prof, je ne prendrais par example pas le risque que quelqu'un
souleve ce point (mais je suis pas prof).
Je suis pas convaincu que std::min_element soit vraiment plus compliqué à
comprendre que std::sort (moins util peut etre, mais j'espere que l'esprit
de l'eleve ne sera pas embrouillé par une ligne qui dit
"min_element(tableau)". C'est assez clair pour ne pas demander plus
d'explication).
(même si ca veut evidemment rien dire cette complexité puisqu'on sait
qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant
et un min_element et un max_element, la méthode avec sort perd en terme
de perfs dès un vector de taille 1.
Ca ne m'étonne pas vraiment. Ce que je voulais dire c'est que d'un point de
vue algorithmique, on peut pas vraiment parler de complexité si on sait
qu'on utilise 3 et seulement 3 élements.
Enfin... récuperer l'élement le plus petit en O(n ln(n)) c'est quand même
moche
Oui, et ? En terme de performances, mettre dans un vector et boucler alors qu'on sait très bien qu'il n'y a que trois éléments, c'est moche aussi par rapport à ces critères. Dans le cadre d'un apprentissage, il me semble important de privilégier l'aspect progressif par rapport à l'aspect élégant, quand les deux sont en désacord.
Je pense que quelqu'un qui apprend le C++ peut avoir des connaissances en algorithmie, et ca peut lui sembler étrange, le déranger, qu'on trie un tableau pour récuperer le plus petit / grand élement. Si j'étais prof, je ne prendrais par example pas le risque que quelqu'un souleve ce point (mais je suis pas prof). Je suis pas convaincu que std::min_element soit vraiment plus compliqué à comprendre que std::sort (moins util peut etre, mais j'espere que l'esprit de l'eleve ne sera pas embrouillé par une ligne qui dit "min_element(tableau)". C'est assez clair pour ne pas demander plus d'explication).
(même si ca veut evidemment rien dire cette complexité puisqu'on sait qu'on aura toujours 3 et seulement 3 élements).
Nop, par contre je viens de faire le test (VC++ 7.1), et même en faisant et un min_element et un max_element, la méthode avec sort perd en terme de perfs dès un vector de taille 1.
Ca ne m'étonne pas vraiment. Ce que je voulais dire c'est que d'un point de vue algorithmique, on peut pas vraiment parler de complexité si on sait qu'on utilise 3 et seulement 3 élements.
-- Vincent
kanze
Serge Paccalin wrote in message news:<12hg04zawhx73$...
Petit problème d'arrondi. Deux solutions : 1. Faire de moyenne un double (et diviser par 3.0). 2. Augmenter la somme avant de diviser, pour que le troncage de la division donne un entier plus proche de la réalité.
Bonne rémarque. Mais en fait, il y a un problème même avant -- il y a risque de débordement. Alors, le mieux serait peut-être de ne travaillait qu'avec les doubles, donc :
Note bien qu'en sortie, l'arrondi se fait comme il faut. Alors, le truc est de garder la valeur en double jusqu'à la sortie.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Serge Paccalin <sp@mailclub.no.spam.net.invalid> wrote in message
news:<12hg04zawhx73$.dlg@canttouchthis-127.0.0.1>...
Petit problème d'arrondi.
Deux solutions :
1. Faire de moyenne un double (et diviser par 3.0).
2. Augmenter la somme avant de diviser, pour que le troncage de la
division donne un entier plus proche de la réalité.
Bonne rémarque. Mais en fait, il y a un problème même avant -- il y a
risque de débordement. Alors, le mieux serait peut-être de ne
travaillait qu'avec les doubles, donc :
Serge Paccalin wrote in message news:<12hg04zawhx73$...
Petit problème d'arrondi. Deux solutions : 1. Faire de moyenne un double (et diviser par 3.0). 2. Augmenter la somme avant de diviser, pour que le troncage de la division donne un entier plus proche de la réalité.
Bonne rémarque. Mais en fait, il y a un problème même avant -- il y a risque de débordement. Alors, le mieux serait peut-être de ne travaillait qu'avec les doubles, donc :
Note bien qu'en sortie, l'arrondi se fait comme il faut. Alors, le truc est de garder la valeur en double jusqu'à la sortie.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Loïc Joly wrote in message news:<cctc44$ff5$...
Twxs wrote:
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser le for_each pour utiliser plusieurs effectuer differentes operation sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les conteneurs et les algorithmes. Donc, probablement pas en chapître 1 (encore que j'imagine que std::string et std::vector peuvent arriver déjà en chapître 1).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<cctc44$ff5$2@news-reader3.wanadoo.fr>...
Twxs wrote:
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser
le for_each pour utiliser plusieurs effectuer differentes operation
sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond
d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les
conteneurs et les algorithmes. Donc, probablement pas en chapître 1
(encore que j'imagine que std::string et std::vector peuvent arriver
déjà en chapître 1).
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser le for_each pour utiliser plusieurs effectuer differentes operation sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les conteneurs et les algorithmes. Donc, probablement pas en chapître 1 (encore que j'imagine que std::string et std::vector peuvent arriver déjà en chapître 1).
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
"Alexandre" wrote in message news:<40f2d166$0$7726$...
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts, notes bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ça, c'est une question de goût. Personnellement, je préfère le ||, pour diverses raisons. Mais j'en connais qui préfère « or ». Les goûts et les couleurs ne se discutent pas.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Alexandre" <alex.g@netcourrier.com> wrote in message
news:<40f2d166$0$7726$626a14ce@news.free.fr>...
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts,
notes bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ça, c'est une question de goût. Personnellement, je préfère le ||, pour
diverses raisons. Mais j'en connais qui préfère « or ». Les goûts et les
couleurs ne se discutent pas.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"Alexandre" wrote in message news:<40f2d166$0$7726$...
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts, notes bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ça, c'est une question de goût. Personnellement, je préfère le ||, pour diverses raisons. Mais j'en connais qui préfère « or ». Les goûts et les couleurs ne se discutent pas.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm
writes:
Loïc Joly wrote in message news:<cctc44$ff5$...
Twxs wrote:
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser le for_each pour utiliser plusieurs effectuer differentes operation sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les conteneurs et les algorithmes. Donc, probablement pas en chapître 1 (encore que j'imagine que std::string et std::vector peuvent arriver déjà en chapître 1).
Bof. Cela ne m'étonnerais pas qu'il s'agisse d'une sorte de Hello World, comme l'a dit Fabien (ou Loïc ?), où l'auteur, sans doute de chez Micro Application, s'attend à la réponse :
#include <iostream.h> void main() { int first ,deuxieme, trois; cin>> first>>deuxieme >> trois ; cout<< (first+ deuxieme +trois) ; cout << " n " ... }
En partie parce qu'il n'en voit pas d'autre, d'ailleurs.
--drkm
kanze@gabi-soft.fr writes:
Loïc Joly <loic.actarus.joly@wanadoo.fr> wrote in message
news:<cctc44$ff5$2@news-reader3.wanadoo.fr>...
Twxs wrote:
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser
le for_each pour utiliser plusieurs effectuer differentes operation
sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond
d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les
conteneurs et les algorithmes. Donc, probablement pas en chapître 1
(encore que j'imagine que std::string et std::vector peuvent arriver
déjà en chapître 1).
Bof. Cela ne m'étonnerais pas qu'il s'agisse d'une sorte de Hello
World, comme l'a dit Fabien (ou Loïc ?), où l'auteur, sans doute de
chez Micro Application, s'attend à la réponse :
#include <iostream.h>
void main()
{
int first ,deuxieme,
trois;
cin>> first>>deuxieme >> trois ;
cout<< (first+ deuxieme +trois) ;
cout << " n "
...
}
En partie parce qu'il n'en voit pas d'autre, d'ailleurs.
s'il s'agit d'un livre sur le c++, le but est peut etre d'utiliser le for_each pour utiliser plusieurs effectuer differentes operation sur un conteneur. Sinon, j'avoue ne pas comprendre l'interet profond d'un tel exercice...
Ca dépend peut-être si on est chapitre 1 ou chapitre 152.
Pas vraiment. Un tel exercise n'a aucun intérêt avant d'avoir abordé les conteneurs et les algorithmes. Donc, probablement pas en chapître 1 (encore que j'imagine que std::string et std::vector peuvent arriver déjà en chapître 1).
Bof. Cela ne m'étonnerais pas qu'il s'agisse d'une sorte de Hello World, comme l'a dit Fabien (ou Loïc ?), où l'auteur, sans doute de chez Micro Application, s'attend à la réponse :
#include <iostream.h> void main() { int first ,deuxieme, trois; cin>> first>>deuxieme >> trois ; cout<< (first+ deuxieme +trois) ; cout << " n " ... }
En partie parce qu'il n'en voit pas d'autre, d'ailleurs.
--drkm
Alexandre
"Serge Paccalin" a écrit dans le message de news:
Le lundi 12 juillet 2004 à 19:59:12, Alexandre a écrit dans fr.comp.lang.c++ :
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts, notes
bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ne parle pas trop vite...
certes, la syntaxe existe mais je ne l'aime pas trop... Parce que ce n'est pas (vraiment) un opérateur (à moins que je ne me trompe, on ne peut surcharger operator or) mais un mot-clé alternatif.
"Serge Paccalin" <sp@mailclub.no.spam.net.invalid> a écrit dans le message
de news:1nhk8be9dpnoe.dlg@canttouchthis-127.0.0.1...
Le lundi 12 juillet 2004 à 19:59:12, Alexandre a écrit dans
fr.comp.lang.c++ :
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts,
notes
bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ne parle pas trop vite...
certes, la syntaxe existe mais je ne l'aime pas trop... Parce que ce n'est
pas (vraiment) un opérateur (à moins que je ne me trompe, on ne peut
surcharger operator or) mais un mot-clé alternatif.
Le lundi 12 juillet 2004 à 19:59:12, Alexandre a écrit dans fr.comp.lang.c++ :
if ( nombre1 < nombre2 or nombre1 < nombre3 )
en plus de toutes les (très pertinentes) remarques des autres posts, notes
bien que le "OU" logique en C++ ne s'écrit pas "or" mais "||"
Ne parle pas trop vite...
certes, la syntaxe existe mais je ne l'aime pas trop... Parce que ce n'est pas (vraiment) un opérateur (à moins que je ne me trompe, on ne peut surcharger operator or) mais un mot-clé alternatif.
Alexandre
Extrait de la norme :
2.5 Alternative tokens 1 Alternative token representations are provided for some operators and punctuators16). 2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token,except for its spelling17). The set of alternative tokens is defined in Table 2.
exact, j'avais swappé ceci mais je n'aime pas trop les "nouveaux" tokens (à cause du C, peut-être, encore des mauvaises habitudes de prises !)
Extrait de la norme :
2.5 Alternative tokens
1 Alternative token representations are provided for some operators and
punctuators16).
2 In all respects of the language, each alternative token behaves the
same, respectively, as its primary token,except for its spelling17). The
set of alternative tokens is defined in Table 2.
exact, j'avais swappé ceci mais je n'aime pas trop les "nouveaux" tokens (à
cause du C, peut-être, encore des mauvaises habitudes de prises !)
2.5 Alternative tokens 1 Alternative token representations are provided for some operators and punctuators16). 2 In all respects of the language, each alternative token behaves the same, respectively, as its primary token,except for its spelling17). The set of alternative tokens is defined in Table 2.
exact, j'avais swappé ceci mais je n'aime pas trop les "nouveaux" tokens (à cause du C, peut-être, encore des mauvaises habitudes de prises !)
