Avez-vous déjà rencontré du code qui appelle depuis un fichier a.c une
fonction g qui prend en argument l'adresse d'une fonction f définie
static dans un autre fichier b.c ?
En plus je vois pas comment c'est possible à moins d'utiliser une
variable globale.
Je pose la question car K.N. King évoque cette possibilité dans son
manuel de C et je voudrais savoir si ça a un quelconque intérêt et si ça
correspond à une pratique réelle.
[Je ne vois pas trop l'intérêt puisque si on définit une fonction en
classe statique c'est pour limiter son accès depuis un fichier externe à
sa définition et donc c'est circonvenir cette limitation d'accès que
d'utiliser un pointeur vers cette fonction.]
Si ma question n'est pas claire, je placerai ici l'extrait du livre de King.
Pour un exemple industriel, c'est le modèle qu'utilise l'interface PKCS#11 v2 : http://www.rsa.com/rsalabs/node.asp?id!33
In code we trust !! Pour être plus précis, quels fichiers (.c et .h), quelles fonctions static, quelles structures à initialiser ? Tu veux dire que par exemple les pointeurs sur fonctions qui sont dans struct CK_FUNCTION_LIST (fichier pkcs11.h) vont être initialisés vers des fonctions static ? Mais comment peut-on le savoir sans disposer des fichiers d'implémentation ?
Désolé je suis un peu péquenot du C ;)
Hélas, c'est franchement pas un exemple adapté pour péquenot du C. La fonction en question est bien C_GetFunctionList avec le pointeur ppFunctionList qui est rempli par l'appel par un pointeur vers une structure CK_FUNCTION_LIST (donc double indirection afin d'en faire un paramètre "out" vers un tableau statique de fonction qui est contenu dans la librairie).
Les fonctions sont forcément statiques puiqu'elles ne seraient pas utilisables sinon.
Le problème d'une exemple industriel est que les fichiers ne sont pas forcément ni lisibles, ni didactiques.
Par exemple : struct CK_FUNCTION_LIST {
CK_VERSION version; /* Cryptoki version */
/* Pile all the function pointers into the CK_FUNCTION_LIST. */ /* pkcs11f.h has all the information about the Cryptoki * function prototypes. */ #include "pkcs11f.h"
};
pkcs11f.h contenant des choses du type :
CK_PKCS11_FUNCTION_INFO(C_Initialize) #ifdef CK_NEED_ARG_LIST ( CK_VOID_PTR pInitArgs /* if this is not NULL_PTR, it gets * cast to CK_C_INITIALIZE_ARGS_PTR * and dereferenced */ ); #endif
Cette technique évite de définir deux fois les protoypes de fonction, si on les changes dans pkcs11f.h, ils sont automatiquement modifié dans CK_FUNCTION_LIST puisque la définition de la structure inclut récursivement pkcs11f.h, et la macro de type CK_PKCS11_FUNCTION_INFO permet de définir la fonction de manière adapté suivant les cas de figure.
De plus on utilise CK_NEED_ARG_LIST pour rester compatible avec les compilateurs C pré norme ISO qui ne reconnaissent pas les arguments de fonctions.
candide wrote:
Jean-Marc Desperrier a écrit :
Pour un exemple industriel, c'est le modèle qu'utilise l'interface
PKCS#11 v2 :
http://www.rsa.com/rsalabs/node.asp?id!33
In code we trust !! Pour être plus précis, quels fichiers (.c et .h),
quelles fonctions static, quelles structures à initialiser ?
Tu veux dire que par exemple les pointeurs sur fonctions qui sont dans
struct CK_FUNCTION_LIST (fichier pkcs11.h) vont être initialisés vers
des fonctions static ? Mais comment peut-on le savoir sans disposer des
fichiers d'implémentation ?
Désolé je suis un peu péquenot du C ;)
Hélas, c'est franchement pas un exemple adapté pour péquenot du C.
La fonction en question est bien C_GetFunctionList avec le pointeur
ppFunctionList qui est rempli par l'appel par un pointeur vers une
structure CK_FUNCTION_LIST (donc double indirection afin d'en faire un
paramètre "out" vers un tableau statique de fonction qui est contenu
dans la librairie).
Les fonctions sont forcément statiques puiqu'elles ne seraient pas
utilisables sinon.
Le problème d'une exemple industriel est que les fichiers ne sont pas
forcément ni lisibles, ni didactiques.
Par exemple :
struct CK_FUNCTION_LIST {
CK_VERSION version; /* Cryptoki version */
/* Pile all the function pointers into the CK_FUNCTION_LIST. */
/* pkcs11f.h has all the information about the Cryptoki
* function prototypes. */
#include "pkcs11f.h"
};
pkcs11f.h contenant des choses du type :
CK_PKCS11_FUNCTION_INFO(C_Initialize)
#ifdef CK_NEED_ARG_LIST
(
CK_VOID_PTR pInitArgs /* if this is not NULL_PTR, it gets
* cast to CK_C_INITIALIZE_ARGS_PTR
* and dereferenced */
);
#endif
Cette technique évite de définir deux fois les protoypes de fonction, si
on les changes dans pkcs11f.h, ils sont automatiquement modifié dans
CK_FUNCTION_LIST puisque la définition de la structure inclut
récursivement pkcs11f.h, et la macro de type CK_PKCS11_FUNCTION_INFO
permet de définir la fonction de manière adapté suivant les cas de figure.
De plus on utilise CK_NEED_ARG_LIST pour rester compatible avec les
compilateurs C pré norme ISO qui ne reconnaissent pas les arguments de
fonctions.
Pour un exemple industriel, c'est le modèle qu'utilise l'interface PKCS#11 v2 : http://www.rsa.com/rsalabs/node.asp?id!33
In code we trust !! Pour être plus précis, quels fichiers (.c et .h), quelles fonctions static, quelles structures à initialiser ? Tu veux dire que par exemple les pointeurs sur fonctions qui sont dans struct CK_FUNCTION_LIST (fichier pkcs11.h) vont être initialisés vers des fonctions static ? Mais comment peut-on le savoir sans disposer des fichiers d'implémentation ?
Désolé je suis un peu péquenot du C ;)
Hélas, c'est franchement pas un exemple adapté pour péquenot du C. La fonction en question est bien C_GetFunctionList avec le pointeur ppFunctionList qui est rempli par l'appel par un pointeur vers une structure CK_FUNCTION_LIST (donc double indirection afin d'en faire un paramètre "out" vers un tableau statique de fonction qui est contenu dans la librairie).
Les fonctions sont forcément statiques puiqu'elles ne seraient pas utilisables sinon.
Le problème d'une exemple industriel est que les fichiers ne sont pas forcément ni lisibles, ni didactiques.
Par exemple : struct CK_FUNCTION_LIST {
CK_VERSION version; /* Cryptoki version */
/* Pile all the function pointers into the CK_FUNCTION_LIST. */ /* pkcs11f.h has all the information about the Cryptoki * function prototypes. */ #include "pkcs11f.h"
};
pkcs11f.h contenant des choses du type :
CK_PKCS11_FUNCTION_INFO(C_Initialize) #ifdef CK_NEED_ARG_LIST ( CK_VOID_PTR pInitArgs /* if this is not NULL_PTR, it gets * cast to CK_C_INITIALIZE_ARGS_PTR * and dereferenced */ ); #endif
Cette technique évite de définir deux fois les protoypes de fonction, si on les changes dans pkcs11f.h, ils sont automatiquement modifié dans CK_FUNCTION_LIST puisque la définition de la structure inclut récursivement pkcs11f.h, et la macro de type CK_PKCS11_FUNCTION_INFO permet de définir la fonction de manière adapté suivant les cas de figure.
De plus on utilise CK_NEED_ARG_LIST pour rester compatible avec les compilateurs C pré norme ISO qui ne reconnaissent pas les arguments de fonctions.
candide
Jean-Marc Desperrier a écrit :
Le problème d'une exemple industriel est que les fichiers ne sont pas forcément ni lisibles, ni didactiques.
Effectivement, ce code me dépasse largement mais le lire m'a quand même instruit (et je considère que le corpus de code professionnel doit quand même constituer le socle d'un enseignement sérieux du C, en particulier un enseignement avancé du C devrait comporter des analyses de code de la même façon qu'en littérature on fait des analyses de textes).
Le point capital de l'explication c'est en fait le commentaire suivant figurant dans pcks11.h :
/* ============================================================== *[couic] * A CK_FUNCTION_LIST contains *[couic] * a whole slew of function pointers to the routines in * the library. * [couic] * ============================================================== */
Sinon, si j'ai bien compris le code source des implémentations n'est pas disponible, les programmeurs disposent d'un ensemble de headers (qui servent aussi de doc) et qui définissent des fonctions ou plutôt des accès à des fonctions et ils disposent également des binaires qu'il faut ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Je pense que si j'avais lu ce genre d'exemples dans mon apprentissage du C, j'aurais compris plus vite beaucoup de choses (et déjà à quoi sert un header).
Jean-Marc Desperrier a écrit :
Le problème d'une exemple industriel est que les fichiers ne sont pas
forcément ni lisibles, ni didactiques.
Effectivement, ce code me dépasse largement mais le lire m'a quand même
instruit (et je considère que le corpus de code professionnel doit quand
même constituer le socle d'un enseignement sérieux du C, en particulier
un enseignement avancé du C devrait comporter des analyses de code de la
même façon qu'en littérature on fait des analyses de textes).
Le point capital de l'explication c'est en fait le commentaire suivant
figurant dans pcks11.h :
/* ==============================================================
*[couic]
* A CK_FUNCTION_LIST contains
*[couic]
* a whole slew of function pointers to the routines in
* the library.
* [couic]
* ==============================================================
*/
Sinon, si j'ai bien compris le code source des implémentations n'est pas
disponible, les programmeurs disposent d'un ensemble de headers (qui
servent aussi de doc) et qui définissent des fonctions ou plutôt des
accès à des fonctions et ils disposent également des binaires qu'il faut
ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Je pense que si j'avais lu ce genre d'exemples dans mon apprentissage du
C, j'aurais compris plus vite beaucoup de choses (et déjà à quoi sert un
header).
Le problème d'une exemple industriel est que les fichiers ne sont pas forcément ni lisibles, ni didactiques.
Effectivement, ce code me dépasse largement mais le lire m'a quand même instruit (et je considère que le corpus de code professionnel doit quand même constituer le socle d'un enseignement sérieux du C, en particulier un enseignement avancé du C devrait comporter des analyses de code de la même façon qu'en littérature on fait des analyses de textes).
Le point capital de l'explication c'est en fait le commentaire suivant figurant dans pcks11.h :
/* ============================================================== *[couic] * A CK_FUNCTION_LIST contains *[couic] * a whole slew of function pointers to the routines in * the library. * [couic] * ============================================================== */
Sinon, si j'ai bien compris le code source des implémentations n'est pas disponible, les programmeurs disposent d'un ensemble de headers (qui servent aussi de doc) et qui définissent des fonctions ou plutôt des accès à des fonctions et ils disposent également des binaires qu'il faut ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Je pense que si j'avais lu ce genre d'exemples dans mon apprentissage du C, j'aurais compris plus vite beaucoup de choses (et déjà à quoi sert un header).
Jean-Marc Desperrier
candide wrote:
[...] Sinon, si j'ai bien compris le code source des implémentations n'est pas disponible,
En théorie, les en-têtes et *la doc dans le PDF* sont suffisante pour écrire une implémentation.
les programmeurs disposent d'un ensemble de headers (qui servent aussi de doc)
Hélas. La vraie doc, c'est le pdf et les centaines de pages a se taper avant d'avant tout compris et d'implémenter d'une façon correspondant vraiment à cela. Dans la pratique, on voit souvent les gens se guider surtout sur les en-têtes, et lire très superficiellement la doc et les subtilités qu'elle présente et obtenir une implémentation qui pose plein de problèmes d'interopérabilité.
et qui définissent des fonctions ou plutôt des accès à des fonctions et ils disposent également des binaires qu'il faut ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Dans leur projet, ils incluent le fichier pkcs11f.h pour définir les fonctions, et ils écrivent ensuite les .c avec le corps de ces fonctions.
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
candide wrote:
[...]
Sinon, si j'ai bien compris le code source des implémentations n'est pas
disponible,
En théorie, les en-têtes et *la doc dans le PDF* sont suffisante pour
écrire une implémentation.
les programmeurs disposent d'un ensemble de headers (qui
servent aussi de doc)
Hélas. La vraie doc, c'est le pdf et les centaines de pages a se taper
avant d'avant tout compris et d'implémenter d'une façon correspondant
vraiment à cela.
Dans la pratique, on voit souvent les gens se guider surtout sur les
en-têtes, et lire très superficiellement la doc et les subtilités
qu'elle présente et obtenir une implémentation qui pose plein de
problèmes d'interopérabilité.
et qui définissent des fonctions ou plutôt des
accès à des fonctions et ils disposent également des binaires qu'il faut
ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Dans leur projet, ils incluent le fichier pkcs11f.h pour définir les
fonctions, et ils écrivent ensuite les .c avec le corps de ces fonctions.
La compilation doit donner une librairie dynamique qui définie tout ce
qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque
binaire fourni, juste les en-têtes .h
[...] Sinon, si j'ai bien compris le code source des implémentations n'est pas disponible,
En théorie, les en-têtes et *la doc dans le PDF* sont suffisante pour écrire une implémentation.
les programmeurs disposent d'un ensemble de headers (qui servent aussi de doc)
Hélas. La vraie doc, c'est le pdf et les centaines de pages a se taper avant d'avant tout compris et d'implémenter d'une façon correspondant vraiment à cela. Dans la pratique, on voit souvent les gens se guider surtout sur les en-têtes, et lire très superficiellement la doc et les subtilités qu'elle présente et obtenir une implémentation qui pose plein de problèmes d'interopérabilité.
et qui définissent des fonctions ou plutôt des accès à des fonctions et ils disposent également des binaires qu'il faut ensuite lier avec leurs propres fichiers objet, c'est bien cela ?
Dans leur projet, ils incluent le fichier pkcs11f.h pour définir les fonctions, et ils écrivent ensuite les .c avec le corps de ces fonctions.
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
candide
Jean-Marc Desperrier a écrit :
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais ce que je comprends pas c'est que des équipes ont déjà écrit du code d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça a pas l'air trivial.
Jean-Marc Desperrier a écrit :
La compilation doit donner une librairie dynamique qui définie tout ce
qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque
binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais
ce que je comprends pas c'est que des équipes ont déjà écrit du code
d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou
plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça
a pas l'air trivial.
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais ce que je comprends pas c'est que des équipes ont déjà écrit du code d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça a pas l'air trivial.
Sylvain SF
candide wrote on 06/08/2008 16:40:
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais ce que je comprends pas c'est que des équipes ont déjà écrit du code d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça a pas l'air trivial.
la remarque est inexacte pour un module PKCS.11, elle ne s'applique pas systématiquement non plus ailleurs.
concernant une lib. cryptoki, c'est en effet un travail important que de coder un tel module, de plus celui-ci est généralement réalisé pour supporter un hard spécifique (une carte à puce, par exemple), cette librairie est dès lors réalisée par l'éditeur (le vendeur de cartes ou un intégrateur) et "le développeur" ne réalise que sa partie applicative (il utilise les fonctions P.11 afin de réaliser les taches de son application), il ne recode évidemment pas un P.11 complet (comme, en général, un développeur ne doit pas "tout faire" mais plutôt utiliser les API de son OS, plus des APIs boite à outils, plus des APIs tierces (tel un P.11)).
Sylvain.
candide wrote on 06/08/2008 16:40:
La compilation doit donner une librairie dynamique qui définie tout ce
qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque
binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais
ce que je comprends pas c'est que des équipes ont déjà écrit du code
d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou
plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça
a pas l'air trivial.
la remarque est inexacte pour un module PKCS.11, elle ne s'applique pas
systématiquement non plus ailleurs.
concernant une lib. cryptoki, c'est en effet un travail important que
de coder un tel module, de plus celui-ci est généralement réalisé pour
supporter un hard spécifique (une carte à puce, par exemple), cette
librairie est dès lors réalisée par l'éditeur (le vendeur de cartes
ou un intégrateur) et "le développeur" ne réalise que sa partie
applicative (il utilise les fonctions P.11 afin de réaliser les
taches de son application), il ne recode évidemment pas un P.11
complet (comme, en général, un développeur ne doit pas "tout faire"
mais plutôt utiliser les API de son OS, plus des APIs boite à outils,
plus des APIs tierces (tel un P.11)).
La compilation doit donner une librairie dynamique qui définie tout ce qui est nécessaire, sans avoir eu besoin d'utiliser un quelconque binaire fourni, juste les en-têtes .h
OK, donc j'avais mal compris, c'est au développeur de tout faire. Mais ce que je comprends pas c'est que des équipes ont déjà écrit du code d'implémentation pour cet API, je vois pas l'intérêt qu'une autre ou plein d'autres d'ailleurs aillent refaire tout le boutot, surtout que ça a pas l'air trivial.
la remarque est inexacte pour un module PKCS.11, elle ne s'applique pas systématiquement non plus ailleurs.
concernant une lib. cryptoki, c'est en effet un travail important que de coder un tel module, de plus celui-ci est généralement réalisé pour supporter un hard spécifique (une carte à puce, par exemple), cette librairie est dès lors réalisée par l'éditeur (le vendeur de cartes ou un intégrateur) et "le développeur" ne réalise que sa partie applicative (il utilise les fonctions P.11 afin de réaliser les taches de son application), il ne recode évidemment pas un P.11 complet (comme, en général, un développeur ne doit pas "tout faire" mais plutôt utiliser les API de son OS, plus des APIs boite à outils, plus des APIs tierces (tel un P.11)).
Avez-vous d�j� rencontr� du code qui appelle depu is un fichier a.c une fonction g qui prend en argument l'adresse d'une fonction f d�fin ie static dans un autre fichier b.c ?
Je pose la question car K.N. King �voque cette possibilitï¿ ½ dans son manuel de C et je voudrais savoir si �a a un quelconque intï¿ ½r�t et si �a correspond � une pratique r�elle.
Oui et oui.
[Je ne vois pas trop l'int�r�t puisque si on d�fi nit une fonction en classe statique c'est pour limiter son acc�s depuis un fichier ex terne � sa d�finition et donc c'est circonvenir cette limitation d'accï ¿½s que d'utiliser un pointeur vers cette fonction.]
Avez-vous d�j� rencontr� du code qui appelle depu is un fichier a.c une
fonction g qui prend en argument l'adresse d'une fonction f d�fin ie
static dans un autre fichier b.c ?
Je pose la question car K.N. King �voque cette possibilitï¿ ½ dans son
manuel de C et je voudrais savoir si �a a un quelconque intï¿ ½r�t et si �a
correspond � une pratique r�elle.
Oui et oui.
[Je ne vois pas trop l'int�r�t puisque si on d�fi nit une fonction en
classe statique c'est pour limiter son acc�s depuis un fichier ex terne �
sa d�finition et donc c'est circonvenir cette limitation d'accï ¿½s que
d'utiliser un pointeur vers cette fonction.]
Avez-vous d�j� rencontr� du code qui appelle depu is un fichier a.c une fonction g qui prend en argument l'adresse d'une fonction f d�fin ie static dans un autre fichier b.c ?
Je pose la question car K.N. King �voque cette possibilitï¿ ½ dans son manuel de C et je voudrais savoir si �a a un quelconque intï¿ ½r�t et si �a correspond � une pratique r�elle.
Oui et oui.
[Je ne vois pas trop l'int�r�t puisque si on d�fi nit une fonction en classe statique c'est pour limiter son acc�s depuis un fichier ex terne � sa d�finition et donc c'est circonvenir cette limitation d'accï ¿½s que d'utiliser un pointeur vers cette fonction.]
Le retour d'Emmanuel Delahaye sur fclc, l'événement de l'été 2008, le forum va enfin redémarrer !!!!!!!!!!!!!!
-ed- a écrit :
Oui, aucun problème. C'est une pratique courante.Si c'est l'inline automatique qui t'inquiète,
L'inline ne m'inquiète pas car je sais à peine ce que c'est. Pour moi, inline c'est du C99 que je ne cherche pas à connaître et si j'ai compris entre les lignes de ton message, l'inlining c'est de l'optimisation du compilateur. Moi, je m'en tiens pour l'instant à ça :
"the behavior of an abstract machine in which issues of optimization are irrelevant."
j'ai pas assez de neurones comme tu dis.
C'est vrai que pour un programmeur en situation réelle, ce n'est pas "irrelevant" mais dans l'apprentissage du C, c'est à la marge, pour moi connaître ça, c'est la myrtille sur la cerise sur le gâteau.
En plus je vois pas comment c'est possible � moins d'utiliser une variable globale.
Je ne vois pas à quoi servirait une globale ici. Des données contextuelles, oui.
Je connais ta prose, merci mais j'ai trouvé la courte remarque de Marc Espié (Message-ID: <g6njj6$19h1$) beaucoup plus instructive surtout accompagné de l'exemple simple que j'ai rapporté de clc.
Oui et oui.
Ça par contre ça a de l'importance pour moi car je sais que tu es un programmeur du terrain.
[Je ne vois pas trop l'int�r�t puisque si on d�finit une fonction en classe statique c'est pour limiter son acc�s depuis un fichier externe � sa d�finition et donc c'est circonvenir cette limitation d'acc�s que d'utiliser un pointeur vers cette fonction.]
L'intérêt est d'y accéder via des voies connues et contrôlables (droits d'accès, 'patte blanche',
Bon, ça je veux bien même s'il me faudrait un contexte pour bien comprendre.
stats etc.)
Ça je sais pas ce que c'est.
Sinon, tes arguments ne sont pas ceux qui ont été donnés par ailleurs, enfin pour ce qui est du plus important, à savoir la non-pollution de l'espace de noms.
Le retour d'Emmanuel Delahaye sur fclc, l'événement de l'été 2008, le
forum va enfin redémarrer !!!!!!!!!!!!!!
-ed- a écrit :
Oui, aucun problème. C'est une pratique courante.Si c'est l'inline
automatique qui t'inquiète,
L'inline ne m'inquiète pas car je sais à peine ce que c'est. Pour moi,
inline c'est du C99 que je ne cherche pas à connaître et si j'ai compris
entre les lignes de ton message, l'inlining c'est de l'optimisation du
compilateur. Moi, je m'en tiens pour l'instant à ça :
"the behavior of an abstract machine in which issues of optimization are
irrelevant."
j'ai pas assez de neurones comme tu dis.
C'est vrai que pour un programmeur en situation réelle, ce n'est pas
"irrelevant" mais dans l'apprentissage du C, c'est à la marge, pour moi
connaître ça, c'est la myrtille sur la cerise sur le gâteau.
En plus je vois pas comment c'est possible � moins d'utiliser une
variable globale.
Je ne vois pas à quoi servirait une globale ici. Des données
contextuelles, oui.
Je connais ta prose, merci mais j'ai trouvé la courte remarque de Marc
Espié (Message-ID: <g6njj6$19h1$1@biggoron.nerim.net>) beaucoup plus
instructive surtout accompagné de l'exemple simple que j'ai rapporté de clc.
Oui et oui.
Ça par contre ça a de l'importance pour moi car je sais que tu es un
programmeur du terrain.
[Je ne vois pas trop l'int�r�t puisque si on d�finit une fonction en
classe statique c'est pour limiter son acc�s depuis un fichier externe �
sa d�finition et donc c'est circonvenir cette limitation d'acc�s que
d'utiliser un pointeur vers cette fonction.]
L'intérêt est d'y accéder via des voies connues et contrôlables
(droits d'accès, 'patte blanche',
Bon, ça je veux bien même s'il me faudrait un contexte pour bien comprendre.
stats etc.)
Ça je sais pas ce que c'est.
Sinon, tes arguments ne sont pas ceux qui ont été donnés par ailleurs,
enfin pour ce qui est du plus important, à savoir la non-pollution de
l'espace de noms.
Le retour d'Emmanuel Delahaye sur fclc, l'événement de l'été 2008, le forum va enfin redémarrer !!!!!!!!!!!!!!
-ed- a écrit :
Oui, aucun problème. C'est une pratique courante.Si c'est l'inline automatique qui t'inquiète,
L'inline ne m'inquiète pas car je sais à peine ce que c'est. Pour moi, inline c'est du C99 que je ne cherche pas à connaître et si j'ai compris entre les lignes de ton message, l'inlining c'est de l'optimisation du compilateur. Moi, je m'en tiens pour l'instant à ça :
"the behavior of an abstract machine in which issues of optimization are irrelevant."
j'ai pas assez de neurones comme tu dis.
C'est vrai que pour un programmeur en situation réelle, ce n'est pas "irrelevant" mais dans l'apprentissage du C, c'est à la marge, pour moi connaître ça, c'est la myrtille sur la cerise sur le gâteau.
En plus je vois pas comment c'est possible � moins d'utiliser une variable globale.
Je ne vois pas à quoi servirait une globale ici. Des données contextuelles, oui.
Je connais ta prose, merci mais j'ai trouvé la courte remarque de Marc Espié (Message-ID: <g6njj6$19h1$) beaucoup plus instructive surtout accompagné de l'exemple simple que j'ai rapporté de clc.
Oui et oui.
Ça par contre ça a de l'importance pour moi car je sais que tu es un programmeur du terrain.
[Je ne vois pas trop l'int�r�t puisque si on d�finit une fonction en classe statique c'est pour limiter son acc�s depuis un fichier externe � sa d�finition et donc c'est circonvenir cette limitation d'acc�s que d'utiliser un pointeur vers cette fonction.]
L'intérêt est d'y accéder via des voies connues et contrôlables (droits d'accès, 'patte blanche',
Bon, ça je veux bien même s'il me faudrait un contexte pour bien comprendre.
stats etc.)
Ça je sais pas ce que c'est.
Sinon, tes arguments ne sont pas ceux qui ont été donnés par ailleurs, enfin pour ce qui est du plus important, à savoir la non-pollution de l'espace de noms.
Antoine Leca
En news:, -ed- <emmanuel.delahaye> va escriure:
Tiens, un revenant...
Antoine
En news:ddc51296-bf51-43c0-b4ec-f1919daa3550@e39g2000hsf.googlegroups.com,
-ed- <emmanuel.delahaye> va escriure:
