Et puis, après tout, quel que soit le langage compilé, au bout du compte ce que fait le compilateur, c´est transformer le code en assembleur, ceci afin d´accélérer les choses.

oui j´ai jamais dis le contraire, de plus les dernières cartes graphiques nous font replonger également dans un autre style d´assembleur ( pour la prog des shaders), mais si AVANT il était possible de créer des applis/jeux entièrement en assembleur, la complexité des softs d´aujourd´hui fait que cela est impossible ( à moins de passer 4 à 5 fois plus de temps en développement). Et cela rendrait la totalité du code non portable ! Alors qu´un prog en C/C++ + qques routines en assembleur, c´est déjà plus réaliste.

< <la complexité des softs d´aujourd´hui fait que cela est impossible ( à moins de passer 4 à 5 fois plus de temps en développement).>>

Coder une application entierement avec MASM32, ça se rapproche finalement beaucoup du C. T´as quoi ? Un peu plus de complexité à gérer ( une ligne du genre if(func(++n)) doit évidemment se décomposer un petit peu en assembleur) et d´un autre côté un peu plus de liberté. Avec un bon IDE, genre RADasm, qui se rapproche de vs . net, et qui est même parfois mieux je trouve, c´est ma foi agréable et pas si lent que ça de coder une appli win32 en asm.

" c´est ma foi agréable et pas si lent que ça de coder une appli win32 en asm."

je demande à voir

" une ligne du genre if(func(++n)) doit évidemment se décomposer un petit peu en assembleur"

Bah vi c´est le principe même de l´assembleur. C´est bien pour cela qu´un développement 100% asm ne peut être envisagé dans le monde pro : problème de temps, problème de maintenance, problème de portabilité. La seule utilité et le seul gain se fait sur les parties critiques.

A moins de développer pour une architecture bien précise, où l´optimisation est primordiale ( plateforme dédiée, par ex sur les consoles de jeux style GBA ou pour du développement temps réel)...