J'approuve, mais 4a ne doit pas être une excuse pour programmer comme un cochon. Je viens de trouver du code qui, pour trouver la valeur maxi dans une liste la trie puis garde la première valeur (et jette le reste!) ...
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Philippe Guglielmetti wrote:
J'approuve, mais 4a ne doit pas être une excuse pour programmer comme
un cochon. Je viens de trouver du code qui, pour trouver la valeur
maxi dans une liste la trie puis garde la première valeur (et jette
le reste!) ...
Et ? A l'heure où la ressource à optimiser est souvent le temps
développeur, pour du code non critique, je n'ai rien contre cet algo.
J'approuve, mais 4a ne doit pas être une excuse pour programmer comme un cochon. Je viens de trouver du code qui, pour trouver la valeur maxi dans une liste la trie puis garde la première valeur (et jette le reste!) ...
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Jean-Noël Mégoz
"Loïc Joly" a écrit dans le message de news:cif5si$ivm$
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles ! Même si on ne veut pas utiliser la STL ou une autre librairy, il y a des méthodes plus efficaces...
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:cif5si$ivm$1@news-reader2.wanadoo.fr...
Et ? A l'heure où la ressource à optimiser est souvent le temps
développeur, pour du code non critique, je n'ai rien contre cet algo.
--
Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le
programmeur a osé trier une liste... par un tri à bulles !
Même si on ne veut pas utiliser la STL ou une autre librairy, il y a des
méthodes plus efficaces...
"Loïc Joly" a écrit dans le message de news:cif5si$ivm$
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles ! Même si on ne veut pas utiliser la STL ou une autre librairy, il y a des méthodes plus efficaces...
Jean-Marc Bourguet
"Jean-Noël Mégoz" writes:
"Loïc Joly" a écrit dans le message de news:cif5si$ivm$
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles !
Il y a des cas où c'est l'algo le plus adapté.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Loïc Joly" <loic.actarus.joly@wanadoo.fr> a écrit dans le message de
news:cif5si$ivm$1@news-reader2.wanadoo.fr...
Et ? A l'heure où la ressource à optimiser est souvent le temps
développeur, pour du code non critique, je n'ai rien contre cet algo.
--
Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le
programmeur a osé trier une liste... par un tri à bulles !
Il y a des cas où c'est l'algo le plus adapté.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Loïc Joly" a écrit dans le message de news:cif5si$ivm$
Et ? A l'heure où la ressource à optimiser est souvent le temps développeur, pour du code non critique, je n'ai rien contre cet algo.
-- Loïc
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles !
Il y a des cas où c'est l'algo le plus adapté.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Michel Michaud
"Jean-Noël Mégoz" a écrit dans le message de news: 414b42e1$0$12625$
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles !
Et pour trier une liste, tu connais quoi comme méthode simple à programmer sans erreur facilement ? Tout étant relatif, s'il n'y a pas des millions d'éléments, on pourrait bien ne pas voir la différence entre cet algo et un autre bien plus sophistiqué, qui prendrait beaucoup plus de temps à programmer correctement. (je précise que si on utilise std::list, il est encore plus facile d'utiliser list::sort...)
Même si on ne veut pas utiliser la STL ou une autre librairy, il y a des méthodes plus efficaces...
C'est sûr, mais le coût peut être prohibitif ailleurs que dans le temps d'exécution (c'est un peu la même raison qui nous permet de programmer en C++ plutôt qu'en langage d'assemblage).
-- -- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Jean-Noël Mégoz" <nospam_jnmegoz@infonie.fr> a écrit dans le message de
news: 414b42e1$0$12625$626a14ce@news.free.fr...
Oui, enfin, y'a des limites : j'ai repris dernièrement un code
C++ où le programmeur a osé trier une liste... par un tri à
bulles !
Et pour trier une liste, tu connais quoi comme méthode simple
à programmer sans erreur facilement ? Tout étant relatif, s'il
n'y a pas des millions d'éléments, on pourrait bien ne pas voir
la différence entre cet algo et un autre bien plus sophistiqué,
qui prendrait beaucoup plus de temps à programmer correctement.
(je précise que si on utilise std::list, il est encore plus
facile d'utiliser list::sort...)
Même si on ne veut pas utiliser la STL ou une autre librairy,
il y a des méthodes plus efficaces...
C'est sûr, mais le coût peut être prohibitif ailleurs que dans
le temps d'exécution (c'est un peu la même raison qui nous
permet de programmer en C++ plutôt qu'en langage d'assemblage).
--
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
"Jean-Noël Mégoz" a écrit dans le message de news: 414b42e1$0$12625$
Oui, enfin, y'a des limites : j'ai repris dernièrement un code C++ où le programmeur a osé trier une liste... par un tri à bulles !
Et pour trier une liste, tu connais quoi comme méthode simple à programmer sans erreur facilement ? Tout étant relatif, s'il n'y a pas des millions d'éléments, on pourrait bien ne pas voir la différence entre cet algo et un autre bien plus sophistiqué, qui prendrait beaucoup plus de temps à programmer correctement. (je précise que si on utilise std::list, il est encore plus facile d'utiliser list::sort...)
Même si on ne veut pas utiliser la STL ou une autre librairy, il y a des méthodes plus efficaces...
C'est sûr, mais le coût peut être prohibitif ailleurs que dans le temps d'exécution (c'est un peu la même raison qui nous permet de programmer en C++ plutôt qu'en langage d'assemblage).
-- -- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
Alexandre Bacquart wrote in message news:<414a8f41$0$20464$...
wrote:
i &= ~1 ;
d'après ce qu'il me semble. Solution qui risque aussi d'être la plus rapide.
Mmh, cela ne fait pas exactement ce que demande l'OP.
En effet, j'ai mal lu l'énoncé. Ça amène à la valeur *paire* inférieure.
Déclarer i en int ou en long a-t-il un effet là-dessus ?
Là aussi, ça dépend. En revanche, avec la solution classique que j'ai présenté, il faudrait se méfier -- ça doit marcher sur une machine complémente à deux dans tous les cas, mais sur une architecture magnitude signée, il vaudrait mieux que le 1 ait le même type que i.
Moi personnellement, je pense qu'il faut toujours se méfier des manipulations de bits en C et C++.
Ça dépend. Pour les unsigned, elles sont assez bien définies. La seule précaution à prendre, c'est de s'assurer qu'on utilise les bons types. Donc, ici, pour un unsigned long, « i &= ~1UL ; ». Pour les signed, c'est effectivement un peu plus délicat -- quand j'ai à manipuler des bits, je ne travaille qu'en unsigned, et dans la mésure de possible, j'évite des long.
-- 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 Bacquart <tek512@hotmail.com> wrote in message
news:<414a8f41$0$20464$626a14ce@news.free.fr>...
kanze@gabi-soft.fr wrote:
i &= ~1 ;
d'après ce qu'il me semble. Solution qui risque aussi d'être la plus
rapide.
Mmh, cela ne fait pas exactement ce que demande l'OP.
En effet, j'ai mal lu l'énoncé. Ça amène à la valeur *paire* inférieure.
Déclarer i en int ou en long a-t-il un effet là-dessus ?
Là aussi, ça dépend. En revanche, avec la solution classique que
j'ai présenté, il faudrait se méfier -- ça doit marcher sur une
machine complémente à deux dans tous les cas, mais sur une
architecture magnitude signée, il vaudrait mieux que le 1 ait le
même type que i.
Moi personnellement, je pense qu'il faut toujours se méfier des
manipulations de bits en C et C++.
Ça dépend. Pour les unsigned, elles sont assez bien définies. La seule
précaution à prendre, c'est de s'assurer qu'on utilise les bons types.
Donc, ici, pour un unsigned long, « i &= ~1UL ; ». Pour les signed,
c'est effectivement un peu plus délicat -- quand j'ai à manipuler des
bits, je ne travaille qu'en unsigned, et dans la mésure de possible,
j'évite des long.
--
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 Bacquart wrote in message news:<414a8f41$0$20464$...
wrote:
i &= ~1 ;
d'après ce qu'il me semble. Solution qui risque aussi d'être la plus rapide.
Mmh, cela ne fait pas exactement ce que demande l'OP.
En effet, j'ai mal lu l'énoncé. Ça amène à la valeur *paire* inférieure.
Déclarer i en int ou en long a-t-il un effet là-dessus ?
Là aussi, ça dépend. En revanche, avec la solution classique que j'ai présenté, il faudrait se méfier -- ça doit marcher sur une machine complémente à deux dans tous les cas, mais sur une architecture magnitude signée, il vaudrait mieux que le 1 ait le même type que i.
Moi personnellement, je pense qu'il faut toujours se méfier des manipulations de bits en C et C++.
Ça dépend. Pour les unsigned, elles sont assez bien définies. La seule précaution à prendre, c'est de s'assurer qu'on utilise les bons types. Donc, ici, pour un unsigned long, « i &= ~1UL ; ». Pour les signed, c'est effectivement un peu plus délicat -- quand j'ai à manipuler des bits, je ne travaille qu'en unsigned, et dans la mésure de possible, j'évite des long.
-- 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
