Est-ce bien raisonanble ? ;)

Il ny' a pas de raison.

Je reprends mon exemple de fonction.

int double_int(int i) 
{ 
   return 2*i; 
} 

d'abord définir un synonyme pour le type de pointeur de fonction (c'est plus pratique):

typedef int *(pfn) (int);

ensuite une variable pour ranger le pointeur

pfn le_pointeur;

Ensuite récupérer le pointeur

le_pointeur = (pfn)GetProcAddress(handle_librairie, TEXT("double_int"));

Et enfin appel

int result = le_pointeur(128);

J'ai écrit ça très vite (pas le temps et fatigué ce soir) mais je pense que ça devrait aller :)

La fonction n'est pas "lancée". Avec LoadLibrary, la dll est seulement chargée dans la mémoire du processus... qui la charge et qui est le "calling process", c'est à dire le processus qui appelle l'API LoadLibrary.
Après ça GetProcAddress permet d'obtenir l'adresse d'une fonction dans cette dll. Le proc de GetProcAddress veut dire procédure, pas process :)

Sous Windows on utilise l'infâme API CreateProcess.
Mais le mieux (le plus facile et direct, sans mettre tes mimimes dans le cambouis de CreatePorcess) est encore de passer par les fonction Posix de ton compilo: execv et compagnie. Vois dans ta doc.

D'autant mieux que les MFC ne sont qu'une très fine couche sur les APIs Windows :lol:
Et oui, les APIs Windows sont une catastrophe. En plus il y a le standard Posix. Mais Kro$soft se fait bien entendu une règle de ne pas l'appliquer :cry:

Je pense bien puisque ce sont des fonctions Posix donc standards. Pour t'éviter de chercher, sous Linux, tu vas les trouver déclarées dans unistd.h comme il se doit. Ce ne sont alors pas des fonctions de ton compilo comme dis dans mon post précédent, mais bien des fonctions système.

Mais en principe les compilos windows fournissent une implémentation. Par exemple tu vas les trouver sous Visual 6.0. Sous Visual 2005, c'est autre chose, tu vas voir dans la doc:

Avec un pipeau équivalent pour les fonctions C telles strcpy, etc.
Sauf que les fonctions n'ont jamais été déclarées dépréciées par les standard C ou C++. Là je parle "strcpy". Quant aux execv et compagnies elles ne sont pas dans le standard C puisque ce sont des fonctions standard Posix.

Mais bref, Microsoft a unilatéralement décidé d'affirmer que tout un paquet de fonctions sont dépréciées dans son 2005. Ce qui est proprement un scandale. D'ailleurs il y a eu des échange de gros mots au comité C++, à cause de cette politique, à l'encontre des types de kro$oft. Le "déprécié" est la version édulcorée que ce que Kro$oft avait l'intention de faire, mais vu la volée de bois vert qu'ils ont pris, ils sont un peu revenus en arrière.
Quant à moi, comme d'autres, je boycotte ce compilateur depuis que je suis tombé sur ça. Dans des entreprises, c'est tout une affaire pour avoir l'autorisation de supprimer un warning. Et je ne parle même pas d'envisager d'utiliser les versions Kro$oft des fonctions.... c'est hors stadard, donc NIET! Si j'utilise Visual 2005 en C++ c'est avec un autre compilateur C++. Et puis bof, parce que j'ai Emacs aussi sous Windows :)

Bon je me suis un peu éloigné du sujet, mais ça soulage, et ça ne fait pas non plus de mal de rétablir un peu la vérité.