Reprise du message précédent :
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.

ca mérite une pelle d'or, de sortir un topic où la dernière intervention date de 2007
 

la différence entre malloc et new vient surtout de l'appel aux constructeurs des divers éléments de ton tableau. Pour les types non primitifs, ca peut coûter cher, et, suivant les cas d'utilisation, on va vouloir faire les initialisations à un autre moment (cas de la mémoire allouée via un reserve dans un vector, par exemple)
 

C'est pas seulement pour un problème d'alisaing qu'on sort les calculs de bornes : suivant les cas, on va vouloir éviter de réévaluer des appels de fonction potentiellement couteux.
 

hashtable != jumptable. Mais dans l'idée, c'est ca
 

Y'a pas d'optim sur la constness, c'est juste de la propreté (rien ne t'empêche de virer un const dans ton code plus loin avec un const_cast)
 

Il y a des cas où ca peut avoir du sens de passer une instance par valeur, tout dépend du contexte.
 

Là, il est plus question de généralité, rien qui nuise vraiment à la lisibilité, on n'est en fait même pas vraiemnt dans des questions d'optimisations mais plutôt de bonnes pratiques.

bonjour à tous,
on va peut-être penser que c'est opportuniste de poster cette question ici..
je commence le C++ et ai seulement le mois d'Août pour arriver à un bon niveau..
 
Pourriez-vous me conseiller sur la façon de procéder pour progresser assez rapidement sur ce mois d'Août..
 
Merci d'avance!

Ne sachant pas quelels bases tu as sur la programmation en général et sur les questions d'architectures, ca va être dur de t'orienter.
En tout cas, en un mois, tu pourras peut-être être opérationnel, mais pour avoir un "bon niveau", ca va sans doute prendre un peu plus de temps ...
 
Commence donc par nous dire ce que tu connais déjà (C ? Java ?) et par jeter un oeil aux bibliolinks (dans le topic qui va bien), tu y trouveras des sites et livres pour apprendre.

y a encore des avantages sur une appli desktop de passer par de l'assembleur intégré ?

non

c'était plus fun avant

si apr fun tu entends inmaintenable, pas portable et totalement contre-productif, oui ...

ué enfin si par exemple tu veux faire du circular shift je suis pas sûr que le code C soit plus productif/maintenable que l'appel à la routine en ASM...

tu veux dire que ton asm il est compiler et processor independant peut etre ...

oui en encapsulant ça dans une lib à la boost et hop

et pourquoi pas faire pareil avec la version  C++ directement :E, c'est juste que tu veux avoir l'air intelligent ou y a une vraie raison ?

la vraie raison c'est que de passer par le C tu fais le postulat que ton compilateur te traduira bien le code C par l'ASM qui va bien dans le cas du circular shift...ce qui n'est hélas pas toujours le cas

c'est pas ton probleme. tu te preoccuperas de ca si et seulement si tes specs de performances ne sont pas atteintes. ET franchement, le circluar shift, ca doit faire parti des trucs qui 1/ sont resolus dans la strength reduction pass 2/ sont dispo sous forme d'intrinsinc C.

oui mais comment tu fais si tu veux tester les flags du FPU par exemple ?

y a ce qu'il faut snas passer par de l'asm que se soi sous gcc ou MSVC.
Le seul truc ou j'ai encore de l'asm, c'est pour rdtsc et encore, pas partout.