Discussion :

[Asmod_D]

Bonjour,

je voudrais savoir les grandes différences entre un callback et un switch ?

car on peut tres bien implémenter des fonctions dans les switch dans une boucle principale alors pourquoi que certains développeurs utilisent des callbacks pour faire la même chose ?



merci !

[ram-0000]

Ce n'est pas tout à fait la même chose.

Autant l'instruction switch fait partie du langage C et C++ autant le callback n'est pas une instruction mais plutôt un concept.

En fait, tu utilises l'instruction switch quand le programme appelant dispose de la condition et des actions à faire suivant la condition.

Dans le cas du callback, c'est quelqu'un d'autre qui appelle la fonction. Ce quelqu'un d'autre peut être le noyau, le framework ou encore un dispositif de l'application.

Un exemple qui me vient à l'esprit, c'est la fonction Microsoft d'énumération des fontes de caractères EnumFonts. Tu appelles la fonction en lui donnant une fonction de rappel (une callback) en 3eme paramètre. Cette fonction de rappel est appelée par le noyau (on va faire simple) pour chaque fonte de caractères.

Ce n'est pas a toi de faire un truc du genre while(GetNextFont(...) != NULL) do something; c'est le noyau qui le fait pour toi en appelant la fonction de callback.

Je trouve que c'est un moyen simple et élégant de faire de l'événementiel.

[Asmod_D]

merci !

[koala01]

Salut,

On pourrait aussi expliquer les choses sous un autre angle.

Une sélection de la fonction appelée au travers d'un switch nécessite de rajouter une valeur chaque fois qu'une nouvelle possibilité est envisagée et rajoutée.

L'avantage de l'utilisation d'un callback est qu'il suffit que le type de retour, le nombre et le type des arguments de la fonction corresponde pour que l'appel de la fonction se fasse...

Y compris s'il s'agit d'une fonction dont l'utilisation n'avait pas été envisagée à l'origine (créée par l'utilisateur, par exemple).

Cela permet donc souvent d'assurer une flexibilité bien plus grande, entre autres basée sur le principe OCP (Open Close Principle : un code doit être ouvert à l'évolution mais fermé à la modificaiton).

Ceci dit, le callback ou pointeur de fonction est assez "archaïque" dans le sens où les foncteurs permettent d'obtenir un résultat similaire, en permettant une meilleure lisibilité

[ram-0000]

Ceci dit, le callback ou pointeur de fonction est assez "archaïque" dans le sens où les foncteurs permettent d'obtenir un résultat similaire, en permettant une meilleure lisibilité

Un foncteur C++, ce n'est pas un pointeur de fonction déguisé ?

[3DArchi]

Un foncteur C++, ce n'est pas un pointeur de fonction déguisé ?

Je sens un peu de provoc' là non ?
Un foncteur c'est plus qu'un pointeur de fonction puisque tu peux avoir un état associé par exemple (variable membre du foncteur). Au delà du pointeur de fonction ou du foncteur (ou d'une lambda), il vaut mieux avoir une approche générique avec un concept 'callable' (c'est à dire à qui on peut appliquer les parenthèses () avec éventuellement des arguments). Ensuite, libre à toi de lui passer un foncteur, un pointeur de fonction ou une lambda

[Emmanuel Deloget]

Un foncteur C++, ce n'est pas un pointeur de fonction déguisé ?

Des différences notables l'emportent sur les points communs :

* un pointeur sur fonction ne peut pas être associé à un environnement implicite ; un foncteur peut l'être.

* un foncteur ne peut pas être vide (mais il peut ne rien faire) ; un pointeur sur fonction peut l'être (== NULL).

* puisqu'un foncteur est un objet, on peut en hériter.

Comme point commun, on a : au niveau du code, l'exécution d'un foncteur ressemble vachtiment bien à l'utilisation d'un pointeur sur fonction.