Il y a déjà une source avec plein de commentaires sur comment le coder plus proprement:
http://www.cppfrance.com/codes/ALGORITHME-EUCLIDE-ETENDU_36400.aspx

Il me semble que vous cherchez la petite bête, abuser ou pas, tel n'est pas la question. Pour moi, le plus important c'est la lisibilité et clairement (l)strcat est la solution la plus claire des trois proposée.

Je vois pas en quoi utiliser lstrcat est abuser, si on raisonne comme çà on recode strcat, strcpy, memcpy, memcmp, memset, ... on en fini plus, autant utiliser les fonctions à notre disposition non ? çà coûte pas plus cher, à moins d'avoir une raison valable pour ne pas le faire.

Je vois pas l'intérêt de coder Main en assembleur, cela ne que compile que sur Visual C++ et c'est pas plus clair; bref on ne gagne absolument rien alors que le reste du code est intéressant.

Il me semble, quoi qu'on en dise mais c'est un avis personnel, que le C++ permet d'avoir une structure plus apparente, je ne dis pas que cela donne un code plus structuré, je dis juste que cette structure, de part sa syntaxe notamment, est souvent plus claire. Par exemple, il y a pas mal de cas où l'héritage est très utile en C++ et dans ces cas, la hiérarchie des classes apparait clairement. Si l'on veut faire le même code en C, bien sûr on va y arrivé mais ce sera moins lisible. Et on peut trouver plein d'autres exemples.

Un autre aspect non négligeable du C++ est le code template car écrire du code générique en C est possible, oui bien sûr que c'est possibble, mais c'est simplement...moche comparé à ce qu'on peut faire en C++.

Enfin, l'apport de la STL est très intéressant dans un programme en C++ même si celui-ci n'utilise pas de structures avancé du C++ explicitemment, notamment string, vector, (priority_)queue... Et dans ce cas, le temps gagné en dévloppement peut-être sensible.

Bref, je ne dis pas que le C est obsolète ni qu'il ne faut pas développer en C mais je dis que ne jurer que par le C c'est parfois se montrer borner. De même pour le C++ bien sûr :)

METANIL: visiblement tu n'a pas compris ma remarque, j'ai bien compris(je ne suis pas encore bête ou du moins je ne crois pas) que le début du débat était ailleurs mais justement le problème est que l'on fini un débat là où il commence et pas n'importe où ailleurs sans préciser où est le début, sinon imagine le bordel que cela cause à la lecture des commentaires d'un post ?!

METANIL, j'aime pas être ne pas être poli, alors je me permettrais d'élever le débat encore un peu plus: à quoi sert ta remarque ? Tu viens embéter le monde avec ton stupide débat C/C++ alors qu'il n'en ai pas même question et tout çà pour quoi, pour faire parler; si tu considère les programmeurs C comme sous-hommes vient pas poster ici et trouve toi un site C++-only.
Très bonne source sinon, très instructive.

Mon dieu ce source date, il faut rajouter "using namespace std;" après "#include <vector>"
Si j'ai le temps je le mettrais à jour pour corriger cela.
Merci pour cette remarque.

En théorie, en utilisant cette technique tu peux faire un FreeLibrary sur n'importe qu'elle DLL mais il doit falloir faire attention à ce que l'on fait pour ne pas planter le processus, quoique en suspendant les autres thread du processus il doit y avoir moyen de bidouiller pas mal.

En fait, lorsque l'on crée une DLL de hook, celle-ci reçoit des messages du shell mais on peut aussi envoyer manuellement des messages donc il suffit d'envoyer un message de ce type au processus: celui sera intercepté par le hook et il pourra alors faire ce qu'il veut:
-soit il charge une autre dll
-soit le code est déjà inclue dans le DLL de hook.

C'est une méthode bien documentée, il suffit de chercher sur Google.