Reprise du message précédent :

 
source preuve resultats car je vois VRAIMENT pas dans quel cas cela est vrai  
(je suis curieux hein, faut prendre la question mal ^^)
 
le premier lien, je troue moche qu'on commence un corus de C++ par du rappel de C et ud ùmelange moche. Un bon cours de C++ ne devrait MEME PAS parler des pointeurs avant d'arriver au polymorphisme et forcer l'utilsiation de string et vector pr ce qui est de gerer les chaines//tableaux dynamiques AMHA.

Ah, mais je crois qu'il est évident que j'ai des gouts de chiottes. Et encore! J'ai fait des efforts pour éviter le syndrome  de l'arc en ciel RGB.
La remarque sur la feuille de style pour impression est très judicieuse et ne m'avait pas effleuré.
 

Pour ma part je suis curieux de savoir pourquoi tu ne fais pas la démonstration inverse.  
Lire http://www.gccsummit.org/2006/view [...] ent_key=18 en préambule pourrait donner des angles d'attaque. Enfin ce que j'en dis...
 

En même temps si je ne me trompe c'est un cours sur le C++, pas Java. On peut vivre dans le dénie de la compatibilité C, mais est-ce bien sage?

sur des gros switchs, j'ai déjà vu des optimisations pas mal avec des tables toussa. faudrait trouver un code de démo. Après le switch c'est quand même plus lisible.

Merci du lien Comme je le disais, l'affirmation se semblait zarb. Merci pour la doc.
 

Pour enseigner la POO et le C++ oui. Enseigner la compatibilité C se fait tard, pour eviter que les gus prennent de sales habitudes à faire des char* machaine = new char[10] etc ...

 
En même temps pour enseigner la POO le C++ n'est pas forcément la panacée    

 
Allez je te donne un indice : c'ets deux cours séparé

La structure de contrôle switch, quand elle peut être utilisée, est préférable car elle permet souvent une meilleure lisibilité du code. De plus au niveau optimisation elle est meilleure car elle ne génère qu'un seul bloc de code, contrairement aux if.
 
Le C++ étant une extension du C, je ne vois pas ce qu'il y a d'illogique à commencer un cours de C++ par quelques notions indispensables de C.  
Si l'ordre des chapitres ne te conviens pas tu peux aussi les lire dans le désordre   Sinon je te conseille vraiment Thinking in C++ de Bruce Heckel d'autant que l'organisation du livre te correspond mieux (ça commence par la notion d'objet).  
L'utilisation de string et vector permet d'éviter les erreurs d'allocations de mémoire et de dépassements de tampon. De plus l'implémentation de la stl est en général très optimisée. Si tu as implémenté tes propres classes plus rapides et sans leak mémoire, ou si tu veux utiliser d'autres librairies, très bien.
 
D'une manière générale, je dirais que si tu veux gagner des picosecondes, mets-toi à l'assembleur !
 
 

Non, le C++ reprends des éléments syntaxiques du C. Point barre.  
 

ouais merci j'en ai besoin
 

ai-je dis le contraire o_O ? et t'inquiétes, oui mes classes de vecteurs et de matrices vont bien plus vite que la STL
 

 
ouais ouais   les intrinsics Altivec et SSE2 me suffisent bien merci

Un peu plus que ça quand même, sinon il n'y aurait pas autant de blahblah dans la spec c++ sur la libc et la compatibilité mémoire des POD et ptêtre d'autres trucs que j'ai oublié/pavu.

 
Certes mais je pense que dissocier l'apprentissage des deux langages et nécessaires.
Le "C with classes" ca va cinq minute ...

On peut pas écrire de Duff's Device avec des if/else if/else
 
Donc Switch/case > if/else

 
setjmp/longjmp FTW

 
  ca je te l'accorde

Soudain je réalise que le nom même du langage est, à coup sur, due à une affreuse méprise: les doigts de Stroustrup dérapent sur le clavier - franchement C++ c'est nawak -, et hop! une génération de programmeux s'entête à croire qu'il y a une filiation. Avouez que c'est ballot.

ca manque de et de

 
 
Suite à ce poste j'ai cherché ce qu'est un Duff's Device mais je ne comprend pas l'intéret de mettre le do while dans le switch. Si on entoure le switch à la place, qu'est-ce que ca change?

J'ai du mal à croire que ce message date de 2007. LOOP est trop lente, il ne faut l'utiliser que si on veut optimiser pour la taille (cf. le guide d'optimisation d'Intel ou d'AMD). Par contre il vaut mieux éviter INC et DEC. Et regarde dans le manuel de ton compilateur comment activer les optimisations, tu risques d'avoir des surprises.  
 
Le chapitre 2 du guide d'AMD parle d'optimisations en C ou en C++ : http://www.amd.com/us-en/assets/co [...] /25112.PDF
Il y a ça aussi : http://agner.org/optimize/optimizing_cpp.pdf

 
si tu savais comme ça me fait plaisir de lire ça  

et ma question?

il y a-t-il une différence de performance ou de taille du code généré entre  

et

j'ai fait un test, c'est plus lent pour la solution 2, j'aurais cru l'inverse
sur une boucle de 10000000 executions
duree1=15625 usec
duree2=46875 usec

bah regarde l'asm généré, le problème avec un bloc de code aussi petit, c'est l'entrelacement avec le code le précédent et le suivant, donc suivant ce qu'il y a autour le compilo peut générer quelque chose de légèrement différent...

Dans ce cas pourquoi les gens préfèrent
while(n-->0)

à

while(n>0)
n--;

?

bah

mais ca va allez vos enculages de mouches là !
Testez des trucs si minimes c'est VRAIMENT n'imp

et le Duffs ?

Carrement. Ca depend completement du compilo ainsi que du code qu'il y a autour. De toutes facons, chercher a gagner en rapidite d'execution sur ce genre de details est le meilleur moyen d'obtenir un code imbitable.

 
t'as raison j'ai soif, je dois avoir une despe pas trop chaude dans le coin  

http://www.youtube.com/watch?v=IYs [...] re=related
(plustôt celle là en fait)
 
duffman est immortel

A partir du moment où ton algo manipule (beaucoup) de données, c'est sur les cache-misses que tu vas perdre le plus de temps. C'est moins visible sur les CPU Intel que sur les daubes qui équipent les consoles, mais c'est quand même déterminant (les CPU Intel ont des prefetchers pour éviter les cache-miss et réordonne l'exécution des instructions pour en minimiser l'impact).
Donc, essaie de minimiser le nombre de lignes de caches utilisées (en groupant les éléments par bloc pour éviter de polluer le cache avec des données inutiles), essaie de parcourir la mémoire 'linéairement' et pas 'aléatoirement', comme ça le prefetcher fonctionnera bien. Au besoin, ajoute des instructions de prefetch si tu peux prédire suffisement à l'avance les accès mémoire.
Tu gagneras beaucoup.

et sinon, ca vaut le coup de toujours passer les variables par références plutot que par valeur? (ca evite une copie de la variable pour rien)

En dessous d'une certaine taille qui dépends des cpu (je dirais entre 8 et 32 octets), il vaut mieux passer par valeur.

sauf que mettre des références à des endroits bien précis aide aussi le compilateur à inliner des méthodes et fonctions plus efficacement. Typiquement, j'ai mesuré pas loin de 15% de gain entre un bon vieux
 

 
et

 
Pincettes ... compilo dependant toussa néanmoins

pour les operateurs il y a en effet un truc, il faut que je retrouve l'article

 
Je suis preneur de la réf.

ouais parce que moi j'aurais tendance à dire que la première forme génère du meilleur code et à éviter les références pour les value type de petite taille. Et j'aurais dit l'inverse, que le fais de mettre des valeurs ça lui donne plus de liberté niveau aliasing, toussa

D'une, si on en est à couper les cheveux en quatre, il faudra m'expliquer pourquoi l'index est signé. Ensuite pour cet opérateur je m'attarderai surtout sur le type du retour. Finalement, tout cela n'a pas grande signification hors contexte précis (compilo, révision du compilo, coefficient de marée).

bah, tableau NRC style, avec des indices du styles -N à +N
 

ca manque de const et de ref je sais, c'etait pas la le pb
Tu va pas m'apprendre à ecrire de soperator[] hein
 

Je l'ai dit aussi

 
Bah pas tout le temps :| Typiquement au milieu d'une déscente récursive de types expressiont empaltes, ca enleve aps mal de code inutile.

Je répond avec une certaine connaissance de développement en C et C++.
 

Comme ddéjà dis, c'est une toute petite perte de temps pour un gain en lisibilité et en sureté du code (surtout pour les pointeurs initialisés à NULL).
 

L'allocation avec un new ou un malloc prend à peu de chose près le même temps, cependant il y a deux choses à savoir :
1. Toujours utiliser le couple new/delete OU malloc/free ne surtout pas mixer les deux.
2. Dans les fonctions où la rapidité est cruciale, il faut éviter au maximum l'allocation dynamique qui ne permet pas au compilateur de prévoir l'espace mémoire nécessaire. De plus le delete va avoir ue tendance à fragmenter la mémoire et rendre l'les allocations plus lentes.
 

A priori, une boucle for et aussi rapide qu'un while. Cependant, les bornes de la boucle for sont évalués à chaque passage dans la boucle est non pas au début. Il faut donc déclarer les bornes en const avant la boucle (cela évite l'aliasing mémoire).
 

Il faut préférer les switch (lorsqu'il y a plus de 2 tests) car ils sont gérés par une table de hashage donc plus rapide d'accés.
 

Toujours mettre un const quand on peut. Cela permet de spécifier au compilateur que la variable ne sera pas modifiée est il pourra donc optimiser le code en conséquence.
 

Quand c'est possible, il faut utiliser un passage par référence (lisibilité + rapidité).
 
Bien sur ces optimisations ne sont à utiliser que dans les fonctions dites "critiques". La lisibilité du code est une des priorité du programmeur.