pointeur de fonction de type perso

Emmanuel Delahaye

03/07/2003 à 19:50

In 'fr.comp.lang.c', AG wrote:

Quand une fonction renvoie une valeur, il y a recopie de la valeur
quelque part (dans la pile je pense) au moment ou on sort de la
fonction. Si la valeur est une structure, grosse qui plus est, le
mécanisme devient lourd (les recopies prennent du temps). C'est pour
cela qu'on préfère passer des pointeurs sur les structures plutot que
les structures elles-même, et de la même manière, on préfère renvoyer un
pointeur sur une structure plutôt que la structure elle même, même si
c'est faisable.

Exactement.

Mais ça m'étonne que tu poses la question.

Pour faire frémir mon trollomètre...

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye

03/07/2003 à 20:02

In 'fr.comp.lang.c', Marc Boyer wrote:

Oui, mais de toute façon, la copie doit avoir lieu à un moment
ou un autre, non ? Il faut recopier le résultat calculé à l'endroit

Ben ça dépend :

struct obj
{
char a[123];
char b[456];
};

{
struct obj obj;

init (&obj);
}

avec

void init (struct obj *this)
{
}

ou

struct obj *p_obj = create ();
if (p_obj)
{
init (&obj);

delete (p_obj);
}

avec

struct obj *create (void)
{
struct obj *this = malloc (sizeof *this);
...

return this;
}

Rien a recopier, question de conception...

Si la valeur est une structure, grosse qui plus est, le
mécanisme devient lourd (les recopies prennent du temps).

C'est quoi une "grosse" structure ?

Qui dépasse la taille d'un registre.

Peut-être parce que je n'aime pas trop les règles de programmation
simpliste "on ne retourne pas une structure".

Tu as raison d'en discuter, mais quelques arguments valable, le bon usage et
l'expérience montrent que dans la pratique, il est très rare de retourner une
structure.

L'introduction de pointeur est une source d'erreur (oui, je sais,
les bons programmeurs ne font pas d'erreur de manipulation
de pointeur). Se pose la question de "qui doit libérer la mémoire" ?

C'est vrai, mais on ne peut pas faire de C sans pointeurs, alors autant le
faire bien. Si tu n'aimes pas les pointeurs, je te conseille d'abandonner le
C tout de suite.

Autant je veux bien conseiller le passage de paramêtre par
pointeur, autant pour le retour de fonction...

Mon compilateur Borland C fait un warning si je passe une structure en
paramètre et non son adresse!

Pour ma part, je préfère réfléchir en terme de sémantique,
puis optimiser après mesure du code.

Ca met pas mal en cause la conception détaillée du code, alors autant bien
démarrer tout de suite...

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Oui, mais de toute façon, la copie doit avoir lieu à un moment
ou un autre, non ? Il faut recopier le résultat calculé à l'endroit

Ben ça dépend :

struct obj
{
char a[123];
char b[456];
};

{
struct obj obj;

init (&obj);
}

avec

void init (struct obj *this)
{
}

ou

struct obj *p_obj = create ();
if (p_obj)
{
init (&obj);

delete (p_obj);
}

avec

struct obj *create (void)
{
struct obj *this = malloc (sizeof *this);
...

return this;
}

Rien a recopier, question de conception...

Si la valeur est une structure, grosse qui plus est, le
mécanisme devient lourd (les recopies prennent du temps).

C'est quoi une "grosse" structure ?

Qui dépasse la taille d'un registre.

Peut-être parce que je n'aime pas trop les règles de programmation
simpliste "on ne retourne pas une structure".

Tu as raison d'en discuter, mais quelques arguments valable, le bon usage et
l'expérience montrent que dans la pratique, il est très rare de retourner une
structure.

L'introduction de pointeur est une source d'erreur (oui, je sais,
les bons programmeurs ne font pas d'erreur de manipulation
de pointeur). Se pose la question de "qui doit libérer la mémoire" ?

C'est vrai, mais on ne peut pas faire de C sans pointeurs, alors autant le
faire bien. Si tu n'aimes pas les pointeurs, je te conseille d'abandonner le
C tout de suite.

Autant je veux bien conseiller le passage de paramêtre par
pointeur, autant pour le retour de fonction...

Mon compilateur Borland C fait un warning si je passe une structure en
paramètre et non son adresse!

Pour ma part, je préfère réfléchir en terme de sémantique,
puis optimiser après mesure du code.

Ca met pas mal en cause la conception détaillée du code, alors autant bien
démarrer tout de suite...

--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye

03/07/2003 à 20:07

In 'fr.comp.lang.c', Marc Boyer wrote:

C'est pour ça que la majorité de mes fonctions de
création retourne des structures, ou prennent un pointeur
de structure en paramêtre.
Mais quand je retourne un pointeur de structure, c'est
généralement après un typedef qui cache complètement l'aspect
pointeur de la donnée manipulée.

Un vrai programmeur C ne cache pas ses pointeurs. Un pointeur n'est pas
honteux. Si tu n'aime pas ça, il y a des tas de langages qui se croient
malins en cachant les pointeurs et qui n'attendent que toi...

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Emmanuel Delahaye

03/07/2003 à 20:14

In 'fr.comp.lang.c', Olivier Aumage wrote:

Se pose la question de "qui doit libérer la mémoire" ?

Celui qui l'alloue, autant que possible.

Dans du code très naif, admettons... mais le moindre ADT a un constructeur et
un destructeur séparés. Sans parler des systèmes multitâches ou une tache
productrice va allouer un bloc, l'initialiser, le refiler aux tâches de
traitement, et finalement se faire libérer par la dernière tâche
consommatrice (si tout va bien, sinon, il faut libérer au moindre problème).

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

Horst Kraemer

03/07/2003 à 23:09

On 3 Jul 2003 08:14:29 GMT, Marc Boyer
wrote:

In article <3f02ab02$0$26624$, Nicolas aunai wrote:
bon, j'aif ait un truc qui marche, mais c'est un peu de la chance :
device *(*fct_device)();
qqn peut-il m'expliquer cette notation un peu compliquée ?

Si je l'écris:

(device*) (*fct_device)();

Cela te parait-il plus simple ?

Une erreur de syntaxe te paraît "plus simple"? ;-)

--
Horst

Marc Boyer

04/07/2003 à 14:13

In article , Olivier Aumage wrote:

Marc Boyer writes:
Donc, il est à mon avis préférable de ne pas risquer l'un des deux
premiers cas en utilisant memcpy explicitement.

OK

Sans compter qu'avec les mécanismes
de cache, on peut vouloir préférer travailler avec la pile
(espace contigue en mémoire, facilement dans le cache) qu'avec
de la mémoire éparpillée partout.

Si la structure a été remplie/initialisée/modifiée avant l'appel de la
fonction, elle sera sans doute également dans le cache (au moins le
second niveau).

Le débat se situait sur les fonctions qui retourne quelque
chose, ce qui, si on laisse de côté les solutions de type
"strcat", "realloc", ou le pointeur en sortie est liée au
pointeur en entrée, ces fonctions là en général "crées/remplissent
initialisent" la donnée retournée.

Les caches fonctionnent d'autant mieux que les zones de mémoire
utilisées varient peu. Or le fait de traiter de grosses structures sur
la pile va précisément à l'encontre de ce principe.

Tout à fait.

Et puis bon, les compilateurs savent souvent assez
bien supprimer les copies mémoires inutiles.

Je ne parierais pas trop sur ça pour des structures... :-)

Ben, avec tout le travail fait autour de C++, pour lequel
c'est un élement déterminant, je pense que la techno doit
se banaliser quand même. Non ?

C'est quoi une "grosse" structure ?

sizeof(struct ma_structure)) > sizeof(struct ma_structure *))

C'est un critère.

"L'introduction de pointeur est une source d'erreur" n'est-elle donc
pas également une règle un peu simpliste ? ;-)

Si.

L'usage montre qu'avec un minimum de rigueur, l'utilisation de
pointeurs n'apporte pas particulièrement plus de problème qu'autre
chose. Le pointeur est sans doute l'élément central du C. Pourquoi
vouloir le contourner ? :-)

Je ne veux pas le contourner. Je veux l'utiliser quand
il est "nécessaire".

Se pose la question de "qui doit libérer la mémoire" ?

Celui qui l'alloue, autant que possible.

Oui, mais avec les fonctions qui retournent un pointeur,
la signature de la fonction ne permet pas de le déterminer,
il faut aussi lire la doc.
Avec un retour pas valeur, la question ne se pose pas.
Si la sémantique est celle d'un retour par valeur,
faut il vraiment retourner un pointeur pour gagner
4 octets ?

En réalité, c'est moins un problème d'optimisation qu'un problème de
cohérence et d'homogénéité. En utilisant systématiquement des
références, tu n'as plus à alterner entre des niveaux d'indirection
différents (le pointeur vers ta structure devient l'unique point
d'accès à cette structure), tu n'as plus à alterner entre des opérateurs
d'accès différents ('->' devient l'unique opérateur d'accès aux
membres), tu n'as plus à alterner les 'struct s' et les 'struct s *'
dans les déclarations de variables, d'arguments et de valeur de retour.

J'ai peu le problème en fait puisque, hormis situation
trivialle, je manipule peu les structures directement, mais
par un jeu d'opérations (PVO: programmation vaguement objet).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

In article <87y8zf1pve.fsf@wanadoo.nl>, Olivier Aumage wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
Donc, il est à mon avis préférable de ne pas risquer l'un des deux
premiers cas en utilisant memcpy explicitement.

OK

Sans compter qu'avec les mécanismes
de cache, on peut vouloir préférer travailler avec la pile
(espace contigue en mémoire, facilement dans le cache) qu'avec
de la mémoire éparpillée partout.

Si la structure a été remplie/initialisée/modifiée avant l'appel de la
fonction, elle sera sans doute également dans le cache (au moins le
second niveau).

Le débat se situait sur les fonctions qui retourne quelque
chose, ce qui, si on laisse de côté les solutions de type
"strcat", "realloc", ou le pointeur en sortie est liée au
pointeur en entrée, ces fonctions là en général "crées/remplissent
initialisent" la donnée retournée.

Les caches fonctionnent d'autant mieux que les zones de mémoire
utilisées varient peu. Or le fait de traiter de grosses structures sur
la pile va précisément à l'encontre de ce principe.

Tout à fait.

Et puis bon, les compilateurs savent souvent assez
bien supprimer les copies mémoires inutiles.

Je ne parierais pas trop sur ça pour des structures... :-)

Ben, avec tout le travail fait autour de C++, pour lequel
c'est un élement déterminant, je pense que la techno doit
se banaliser quand même. Non ?

C'est quoi une "grosse" structure ?

sizeof(struct ma_structure)) > sizeof(struct ma_structure *))

C'est un critère.

"L'introduction de pointeur est une source d'erreur" n'est-elle donc
pas également une règle un peu simpliste ? ;-)

Si.

L'usage montre qu'avec un minimum de rigueur, l'utilisation de
pointeurs n'apporte pas particulièrement plus de problème qu'autre
chose. Le pointeur est sans doute l'élément central du C. Pourquoi
vouloir le contourner ? :-)

Je ne veux pas le contourner. Je veux l'utiliser quand
il est "nécessaire".

Se pose la question de "qui doit libérer la mémoire" ?

Celui qui l'alloue, autant que possible.

Oui, mais avec les fonctions qui retournent un pointeur,
la signature de la fonction ne permet pas de le déterminer,
il faut aussi lire la doc.
Avec un retour pas valeur, la question ne se pose pas.
Si la sémantique est celle d'un retour par valeur,
faut il vraiment retourner un pointeur pour gagner
4 octets ?

En réalité, c'est moins un problème d'optimisation qu'un problème de
cohérence et d'homogénéité. En utilisant systématiquement des
références, tu n'as plus à alterner entre des niveaux d'indirection
différents (le pointeur vers ta structure devient l'unique point
d'accès à cette structure), tu n'as plus à alterner entre des opérateurs
d'accès différents ('->' devient l'unique opérateur d'accès aux
membres), tu n'as plus à alterner les 'struct s' et les 'struct s *'
dans les déclarations de variables, d'arguments et de valeur de retour.

J'ai peu le problème en fait puisque, hormis situation
trivialle, je manipule peu les structures directement, mais
par un jeu d'opérations (PVO: programmation vaguement objet).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Vous avez filtré cet utilisateur ! Consultez son message

In article , Olivier Aumage wrote:

Marc Boyer writes:
Donc, il est à mon avis préférable de ne pas risquer l'un des deux
premiers cas en utilisant memcpy explicitement.

OK

Sans compter qu'avec les mécanismes
de cache, on peut vouloir préférer travailler avec la pile
(espace contigue en mémoire, facilement dans le cache) qu'avec
de la mémoire éparpillée partout.

Si la structure a été remplie/initialisée/modifiée avant l'appel de la
fonction, elle sera sans doute également dans le cache (au moins le
second niveau).

Le débat se situait sur les fonctions qui retourne quelque
chose, ce qui, si on laisse de côté les solutions de type
"strcat", "realloc", ou le pointeur en sortie est liée au
pointeur en entrée, ces fonctions là en général "crées/remplissent
initialisent" la donnée retournée.

Les caches fonctionnent d'autant mieux que les zones de mémoire
utilisées varient peu. Or le fait de traiter de grosses structures sur
la pile va précisément à l'encontre de ce principe.

Tout à fait.

Et puis bon, les compilateurs savent souvent assez
bien supprimer les copies mémoires inutiles.

Je ne parierais pas trop sur ça pour des structures... :-)

Ben, avec tout le travail fait autour de C++, pour lequel
c'est un élement déterminant, je pense que la techno doit
se banaliser quand même. Non ?

C'est quoi une "grosse" structure ?

sizeof(struct ma_structure)) > sizeof(struct ma_structure *))

C'est un critère.

"L'introduction de pointeur est une source d'erreur" n'est-elle donc
pas également une règle un peu simpliste ? ;-)

Si.

L'usage montre qu'avec un minimum de rigueur, l'utilisation de
pointeurs n'apporte pas particulièrement plus de problème qu'autre
chose. Le pointeur est sans doute l'élément central du C. Pourquoi
vouloir le contourner ? :-)

Je ne veux pas le contourner. Je veux l'utiliser quand
il est "nécessaire".

Se pose la question de "qui doit libérer la mémoire" ?

Celui qui l'alloue, autant que possible.

Oui, mais avec les fonctions qui retournent un pointeur,
la signature de la fonction ne permet pas de le déterminer,
il faut aussi lire la doc.
Avec un retour pas valeur, la question ne se pose pas.
Si la sémantique est celle d'un retour par valeur,
faut il vraiment retourner un pointeur pour gagner
4 octets ?

En réalité, c'est moins un problème d'optimisation qu'un problème de
cohérence et d'homogénéité. En utilisant systématiquement des
références, tu n'as plus à alterner entre des niveaux d'indirection
différents (le pointeur vers ta structure devient l'unique point
d'accès à cette structure), tu n'as plus à alterner entre des opérateurs
d'accès différents ('->' devient l'unique opérateur d'accès aux
membres), tu n'as plus à alterner les 'struct s' et les 'struct s *'
dans les déclarations de variables, d'arguments et de valeur de retour.

J'ai peu le problème en fait puisque, hormis situation
trivialle, je manipule peu les structures directement, mais
par un jeu d'opérations (PVO: programmation vaguement objet).

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Marc Boyer

04/07/2003 à 14:29

Emmanuel Delahaye wrote:

Marc Boyer wrote:

Oui, mais de toute façon, la copie doit avoir lieu à un moment
ou un autre, non ? Il faut recopier le résultat calculé à l'endroit
[SNIP exemple de constructeur allocateur]

Rien a recopier, question de conception...

Oui, ma remarque manquait de précision du contexte.

Qui dépasse la taille d'un registre.

C'est une définition.

Peut-être parce que je n'aime pas trop les règles de programmation
simpliste "on ne retourne pas une structure".

Tu as raison d'en discuter, mais quelques arguments valable, le bon usage et
l'expérience montrent que dans la pratique, il est très rare de retourner une
structure.

J'ai justement posé la question pour connaître les arguments et
le retour d'expérience.

C'est vrai, mais on ne peut pas faire de C sans pointeurs, alors autant le
faire bien. Si tu n'aimes pas les pointeurs, je te conseille d'abandonner le
C tout de suite.

Non, j'utilise des pointeurs quand c'est necessaire.
J'ai toujours en tête la devise de Knuth, qui donnait qque chose comme
"l'optimisation prépaturée est source de toutes les horreurs".

Autant je veux bien conseiller le passage de paramêtre par
pointeur, autant pour le retour de fonction...

Mon compilateur Borland C fait un warning si je passe une structure en
paramètre et non son adresse!

Mais comme c'est un bon compilateur, il te permet d'ajouter
le bon #pragma pour signifier que, à cet endroit là, tu as entendu
son avertissement mais que tu maintiens ce choix de conception. Non ?
Ceci dit, je redis que je différencie code de retour et
passage de paramêtre.

Pour ma part, je préfère réfléchir en terme de sémantique,
puis optimiser après mesure du code.

Ca met pas mal en cause la conception détaillée du code, alors autant bien
démarrer tout de suite...

Ca met surtout à mal si on change la sémantique, ie le plus
souvent qu'on perde une sémantique de valeur, non ? C'est souvent
me cas ? Les données autres que int/floaa/enumt and co ont elles
souvent une sémantique par valeur ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Emmanuel Delahaye wrote:

Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Oui, mais de toute façon, la copie doit avoir lieu à un moment
ou un autre, non ? Il faut recopier le résultat calculé à l'endroit
[SNIP exemple de constructeur allocateur]

Rien a recopier, question de conception...

Oui, ma remarque manquait de précision du contexte.

Qui dépasse la taille d'un registre.

C'est une définition.

Peut-être parce que je n'aime pas trop les règles de programmation
simpliste "on ne retourne pas une structure".

Tu as raison d'en discuter, mais quelques arguments valable, le bon usage et
l'expérience montrent que dans la pratique, il est très rare de retourner une
structure.

J'ai justement posé la question pour connaître les arguments et
le retour d'expérience.

C'est vrai, mais on ne peut pas faire de C sans pointeurs, alors autant le
faire bien. Si tu n'aimes pas les pointeurs, je te conseille d'abandonner le
C tout de suite.

Non, j'utilise des pointeurs quand c'est necessaire.
J'ai toujours en tête la devise de Knuth, qui donnait qque chose comme
"l'optimisation prépaturée est source de toutes les horreurs".

Autant je veux bien conseiller le passage de paramêtre par
pointeur, autant pour le retour de fonction...

Mon compilateur Borland C fait un warning si je passe une structure en
paramètre et non son adresse!

Mais comme c'est un bon compilateur, il te permet d'ajouter
le bon #pragma pour signifier que, à cet endroit là, tu as entendu
son avertissement mais que tu maintiens ce choix de conception. Non ?
Ceci dit, je redis que je différencie code de retour et
passage de paramêtre.

Pour ma part, je préfère réfléchir en terme de sémantique,
puis optimiser après mesure du code.

Ca met pas mal en cause la conception détaillée du code, alors autant bien
démarrer tout de suite...

Ca met surtout à mal si on change la sémantique, ie le plus
souvent qu'on perde une sémantique de valeur, non ? C'est souvent
me cas ? Les données autres que int/floaa/enumt and co ont elles
souvent une sémantique par valeur ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Vous avez filtré cet utilisateur ! Consultez son message

Emmanuel Delahaye wrote:

Marc Boyer wrote:

Oui, mais de toute façon, la copie doit avoir lieu à un moment
ou un autre, non ? Il faut recopier le résultat calculé à l'endroit
[SNIP exemple de constructeur allocateur]

Rien a recopier, question de conception...

Oui, ma remarque manquait de précision du contexte.

Qui dépasse la taille d'un registre.

C'est une définition.

Peut-être parce que je n'aime pas trop les règles de programmation
simpliste "on ne retourne pas une structure".

Tu as raison d'en discuter, mais quelques arguments valable, le bon usage et
l'expérience montrent que dans la pratique, il est très rare de retourner une
structure.

J'ai justement posé la question pour connaître les arguments et
le retour d'expérience.

C'est vrai, mais on ne peut pas faire de C sans pointeurs, alors autant le
faire bien. Si tu n'aimes pas les pointeurs, je te conseille d'abandonner le
C tout de suite.

Non, j'utilise des pointeurs quand c'est necessaire.
J'ai toujours en tête la devise de Knuth, qui donnait qque chose comme
"l'optimisation prépaturée est source de toutes les horreurs".

Autant je veux bien conseiller le passage de paramêtre par
pointeur, autant pour le retour de fonction...

Mon compilateur Borland C fait un warning si je passe une structure en
paramètre et non son adresse!

Mais comme c'est un bon compilateur, il te permet d'ajouter
le bon #pragma pour signifier que, à cet endroit là, tu as entendu
son avertissement mais que tu maintiens ce choix de conception. Non ?
Ceci dit, je redis que je différencie code de retour et
passage de paramêtre.

Pour ma part, je préfère réfléchir en terme de sémantique,
puis optimiser après mesure du code.

Ca met pas mal en cause la conception détaillée du code, alors autant bien
démarrer tout de suite...

Ca met surtout à mal si on change la sémantique, ie le plus
souvent qu'on perde une sémantique de valeur, non ? C'est souvent
me cas ? Les données autres que int/floaa/enumt and co ont elles
souvent une sémantique par valeur ?

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Marc Boyer

04/07/2003 à 14:31

Emmanuel Delahaye wrote:

In 'fr.comp.lang.c', AG wrote:

Mais ça m'étonne que tu poses la question.

Pour faire frémir mon trollomètre...

Non, juste pour entendre les arguments.
Pour affiner les termes du débat.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Marc Boyer

04/07/2003 à 14:32

Horst Kraemer wrote:

On 3 Jul 2003 08:14:29 GMT, Marc Boyer
wrote:

Si je l'écris:

(device*) (*fct_device)();

Cela te parait-il plus simple ?

Une erreur de syntaxe te paraît "plus simple"? ;-)

Honte à moi.
J'ai tendance à considérer que les parenthèses sont en général
sans influence quand elles ne font que souligner des priorités.
Je ferai plus attention.

Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(

Emmanuel Delahaye

04/07/2003 à 16:22

In 'fr.comp.lang.c', Olivier Aumage wrote:

- Soit la fonction appelée gère elle-même l'allocation et dans ce cas
il est préférable de proposer --- dans la même entité logicielle (i.e.
fichier, module, objet, bibliothèque ou autre, suivant l'échelle et le
contexte)--- une fonction pour gérer la libération.

Dans le second cas, il en outre souhaitable que le nom des fonctions
mentionne l'idée d'allocation/libération.

J'utilise le suffixe _dyn. Extrait de la bibliothèque perso:

/* ---------------------------------------------------------------------
STR_sub_dyn ()
---------------------------------------------------------------------
Fait une copie d'une sous chaine entre deux pointeurs
A liberer.
---------------------------------------------------------------------
E : debut
E : fin
--------------------------------------------------------------------- */
char *STR_sub_dyn (char const *const pbeg
,char const *const pend);

/* ---------------------------------------------------------------------
STR_stringize_dyn ()
---------------------------------------------------------------------
Mettre des "" autour d'une chaine
Suppression des blancs en fin de chaine

'abc def ' -> '"abc def"'

A liberer.
---------------------------------------------------------------------
E : chaine initiale
S : chaine resultante
--------------------------------------------------------------------- */
char *STR_stringize_dyn (char const *const s_in);

etc.

--
-ed- [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

pointeur de fonction de type perso

10 réponses

Veuillez sélectionner un problème