Je voudrais faire un tour des différentes plates-formes sous C pour savoir
s'il y existe des équivalents d'une extension Microsoft, les fonctions
"naked".
Une fonction dotée de cet attribut est appelée extérieurement selon la
convention dite cdecl (le code appelant empile les arguments puis la partie
externe de la stackframe, et fait le ménage au retour), mais par contre
aucune stackframe n'est créée du côté interne.
Le but est de laisser le programmeur faire ce qu'il veut ex-nihilo,
généralement avec de l'assembleur inline. C'est très utile dans certains
contextes (drivers par exemple).
Pour ma part, j'y vois une possibilité d'implémentation de la technique
d'enfilage de pseudo-instructions, avec par rapport au goto l'avantage de la
récursivité.
Merci de me dire si vous connaissez des concepts similaires sur les
principales plates-formes (système + compilo) autres que (Windows + Cµsoft).
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule optimale du tableau d'indirection, je vais procéder ainsi a priori, avec donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours de code d'erreur sont une chose très fréquente.
-- -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', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule
optimale du tableau d'indirection, je vais procéder ainsi a priori, avec
donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours
de code d'erreur sont une chose très fréquente.
--
-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/
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule optimale du tableau d'indirection, je vais procéder ainsi a priori, avec donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours de code d'erreur sont une chose très fréquente.
-- -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/
Patrick Brunet
Bonjour.
"Emmanuel Delahaye" a écrit dans le message news:
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule optimale du tableau d'indirection, je vais procéder ainsi a priori, avec donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la p-instruction définit directement le contexte (et éventuellement le choix) de la suivante. Donc a priori il y a un doublet à retourner : l'indice ou pointeur d'instruction, et le repère pour l'espace de travail. Pas question de retourner un struct qui produirait une stackframe, une copie, etc., et donc en fait l'unique valeur de retour n'est pas forcément une solution optimale... J'évaluerai ça en spécifiant le protocole complet.
Merci, Cordialement, PZB
Bonjour.
"Emmanuel Delahaye" <emdelYOURBRA@noos.fr> a écrit dans le message news:
Xns93EBB5DC993F9hsnoservernet@130.133.1.4...
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule
optimale du tableau d'indirection, je vais procéder ainsi a priori, avec
donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les
retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la
p-instruction définit directement le contexte (et éventuellement le choix)
de la suivante.
Donc a priori il y a un doublet à retourner : l'indice ou pointeur
d'instruction, et le repère pour l'espace de travail. Pas question de
retourner un struct qui produirait une stackframe, une copie, etc., et donc
en fait l'unique valeur de retour n'est pas forcément une solution
optimale... J'évaluerai ça en spécifiant le protocole complet.
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Comme je peux maîtriser la valeur des "cases" et donc choisir la formule optimale du tableau d'indirection, je vais procéder ainsi a priori, avec donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la p-instruction définit directement le contexte (et éventuellement le choix) de la suivante. Donc a priori il y a un doublet à retourner : l'indice ou pointeur d'instruction, et le repère pour l'espace de travail. Pas question de retourner un struct qui produirait une stackframe, une copie, etc., et donc en fait l'unique valeur de retour n'est pas forcément une solution optimale... J'évaluerai ça en spécifiant le protocole complet.
Merci, Cordialement, PZB
Patrick Brunet
Bonjour.
"Gabriel Dos Reis" a écrit dans le message news: "Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
[...]
| Cela vaut pour la syntaxe, certes, mais dans mon cas aussi pour des | performances minimales.
"La norme C ne requiert pas qu'une implémentation soit utile, ni performante (avec une définition appropriée de utile ou performante). Une implémentation conforme peut très bien insérer sleep(1000) entre chaque instruction. Donc, parler de « performance minimale » n'a pas beaucoup de sens, je le crains. Cependant, ce qui a peut être un sens, c'est une performance comparative ; et là encore il y a beaucoup de pièges. "
Certes, mais il y a des implicites : le langage C est traditionnellement "l'un des plus performants après l'assembleur pour une plate-forme donnée" (surtout si on évite les idiomes sujets à implémentations anti-performantes, c'était l'objet du thread finalement), et ceci avec une garantie de disponibilité quasi universelle. Donc quand on envisage une plate-forme dont on ne sait rien de plus, disons que l'on met ainsi toutes les chances de son côté pour optenir des performances "optimales". A ce point je suis démuni et je ne peux pas promettre mieux à mes propres Utilisateurs.
On fera donc avec.
Merci, Cordialement,
PZB
Bonjour.
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m34qzujbfh.fsf@uniton.integrable-solutions.net...
"Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
[...]
| Cela vaut pour la syntaxe, certes, mais dans mon cas aussi pour des
| performances minimales.
"La norme C ne requiert pas qu'une implémentation soit utile, ni
performante (avec une définition appropriée de utile ou performante).
Une implémentation conforme peut très bien insérer sleep(1000) entre
chaque instruction. Donc, parler de « performance minimale » n'a pas
beaucoup de sens, je le crains. Cependant, ce qui a peut être un sens,
c'est une performance comparative ; et là encore il y a beaucoup de
pièges. "
Certes, mais il y a des implicites : le langage C est traditionnellement
"l'un des plus performants après l'assembleur pour une plate-forme donnée"
(surtout si on évite les idiomes sujets à implémentations anti-performantes,
c'était l'objet du thread finalement), et ceci avec une garantie de
disponibilité quasi universelle.
Donc quand on envisage une plate-forme dont on ne sait rien de plus, disons
que l'on met ainsi toutes les chances de son côté pour optenir des
performances "optimales". A ce point je suis démuni et je ne peux pas
promettre mieux à mes propres Utilisateurs.
"Gabriel Dos Reis" a écrit dans le message news: "Patrick Brunet" <Patrick.Brunet @ cned.fr> writes:
[...]
| Cela vaut pour la syntaxe, certes, mais dans mon cas aussi pour des | performances minimales.
"La norme C ne requiert pas qu'une implémentation soit utile, ni performante (avec une définition appropriée de utile ou performante). Une implémentation conforme peut très bien insérer sleep(1000) entre chaque instruction. Donc, parler de « performance minimale » n'a pas beaucoup de sens, je le crains. Cependant, ce qui a peut être un sens, c'est une performance comparative ; et là encore il y a beaucoup de pièges. "
Certes, mais il y a des implicites : le langage C est traditionnellement "l'un des plus performants après l'assembleur pour une plate-forme donnée" (surtout si on évite les idiomes sujets à implémentations anti-performantes, c'était l'objet du thread finalement), et ceci avec une garantie de disponibilité quasi universelle. Donc quand on envisage une plate-forme dont on ne sait rien de plus, disons que l'on met ainsi toutes les chances de son côté pour optenir des performances "optimales". A ce point je suis démuni et je ne peux pas promettre mieux à mes propres Utilisateurs.
| Certes, mais il y a des implicites : le langage C est traditionnellement | "l'un des plus performants après l'assembleur pour une plate-forme donnée"
| Certes, mais il y a des implicites : le langage C est traditionnellement
| "l'un des plus performants après l'assembleur pour une plate-forme donnée"
| Certes, mais il y a des implicites : le langage C est traditionnellement | "l'un des plus performants après l'assembleur pour une plate-forme donnée"
c'est un mythe traditionel ;-)
-- Gaby
Emmanuel Delahaye
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Certes, mais il y a des implicites : le langage C est traditionnellement "l'un des plus performants après l'assembleur pour une plate-forme donnée"
Bah, ça dépend comment est écrit le code, et aussi de la qualité du compilateur.
-- -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', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Certes, mais il y a des implicites : le langage C est traditionnellement
"l'un des plus performants après l'assembleur pour une plate-forme
donnée"
Bah, ça dépend comment est écrit le code, et aussi de la qualité du
compilateur.
--
-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/
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
Certes, mais il y a des implicites : le langage C est traditionnellement "l'un des plus performants après l'assembleur pour une plate-forme donnée"
Bah, ça dépend comment est écrit le code, et aussi de la qualité du compilateur.
-- -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
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la p-instruction définit directement le contexte (et éventuellement le choix) de la suivante.
Ok. Désolé de ce reflexe pavlovien!
-- -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', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les
retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la
p-instruction définit directement le contexte (et éventuellement le choix)
de la suivante.
Ok. Désolé de ce reflexe pavlovien!
--
-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/
In 'fr.comp.lang.c', "Patrick Brunet" <Patrick.Brunet @ cned.fr> wrote:
donc des pointeurs de fonctions ordinaires à signature void( void). Ca
Je conseille plutôt int (void) ou int (). C'est plus souple, et les retours
de code d'erreur sont une chose très fréquente.
Dans le contexte de l'enfilage de p-instructions, rien ne passe par les
arguments, et de même le code de retour n'est pas exploité, à la place la p-instruction définit directement le contexte (et éventuellement le choix) de la suivante.
Ok. Désolé de ce reflexe pavlovien!
-- -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/
Patrick Brunet
Bonjour,
"Emmanuel Delahaye" a écrit dans le message news:
Ok. Désolé de ce reflexe pavlovien!
No problemo, j'en ai aussi. C'est même assez instructif d'en devenir conscient et d'apprendre à se demander "n'y a-t-il pas une autre, voire meilleure solution ?".
Tu connais le problème du carré de 9 points, à couper par une polyligne de 4 segments (donc sans lever le crayon) ?
Cordialement, PZB
Bonjour,
"Emmanuel Delahaye" <emdelYOURBRA@noos.fr> a écrit dans le message news:
Xns93ECBC11DDE63hsnoservernet@130.133.1.4...
Ok. Désolé de ce reflexe pavlovien!
No problemo, j'en ai aussi.
C'est même assez instructif d'en devenir conscient et d'apprendre à se
demander "n'y a-t-il pas une autre, voire meilleure solution ?".
Tu connais le problème du carré de 9 points, à couper par une polyligne de 4
segments (donc sans lever le crayon) ?
No problemo, j'en ai aussi. C'est même assez instructif d'en devenir conscient et d'apprendre à se demander "n'y a-t-il pas une autre, voire meilleure solution ?".
Tu connais le problème du carré de 9 points, à couper par une polyligne de 4 segments (donc sans lever le crayon) ?
Cordialement, PZB
Dominique Baldo
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
à couper
Qu'est ce que tu entends par "couper" (un carré ou un point)? Joindre les points?
par une polyligne de 4 segments (donc sans lever le crayon) ?
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
à couper
Qu'est ce que tu entends par "couper" (un carré ou un point)? Joindre
les points?
par une polyligne de 4 segments (donc sans lever le crayon) ?
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
à couper
Qu'est ce que tu entends par "couper" (un carré ou un point)? Joindre les points?
par une polyligne de 4 segments (donc sans lever le crayon) ?
Si je me souviens bien, il faut joindre les 9 points, sans lever le crayon et sans repasser deux fois au même endroit :
. . .
. . .
. . .
Solution en bas.
.-.-.- | / . . . | X . . . |/
(désolé pour la mauvaise qualité de l'ASCII-art)
-- Richard
Patrick Brunet
"Richard Delorme" a écrit dans le message news: 3f59d3e1$0$20946$
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
oui, c'est ça
Si je me souviens bien, il faut joindre les 9 points, sans lever le crayon et sans repasser deux fois au même endroit :
Sisi, dans l'énoncé nominal, il n'est pas interdit de repasser par un ou plusieurs points. En fait, c'est le contraire qui est difficile : passer par tous les points.
.-.-.- | / . . . | X . . . |/
(désolé pour la mauvaise qualité de l'ASCII-art)
C'est effectivement la bonne solution, mais ce qui est intéressant, c'est qu'elle nécessite de sortir du carré, et 8 personnes sur 10 (ne connaissant pas la solution) vont s'arracher les cheveux sans la trouver (essayez autour de vous). S'interdire de sortir d'un périmètre est une contrainte que l'on se donne soi-même instinctivement.
C'est ce qui motivait cette petite digression sur les réflexes pavloviens.
Cordialement, PZB
"Richard Delorme" <abulmo@nospam.fr> a écrit dans le message news:
3f59d3e1$0$20946$7a628cd7@news.club-internet.fr...
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
oui, c'est ça
Si je me souviens bien, il faut joindre les 9 points, sans lever le crayon
et sans repasser deux fois au même endroit :
Sisi, dans l'énoncé nominal, il n'est pas interdit de repasser par un ou
plusieurs points.
En fait, c'est le contraire qui est difficile : passer par tous les points.
.-.-.-
| /
. . .
| X
. . .
|/
(désolé pour la mauvaise qualité de l'ASCII-art)
C'est effectivement la bonne solution, mais ce qui est intéressant, c'est
qu'elle nécessite de sortir du carré, et 8 personnes sur 10 (ne connaissant
pas la solution) vont s'arracher les cheveux sans la trouver (essayez autour
de vous).
S'interdire de sortir d'un périmètre est une contrainte que l'on se donne
soi-même instinctivement.
C'est ce qui motivait cette petite digression sur les réflexes pavloviens.
"Richard Delorme" a écrit dans le message news: 3f59d3e1$0$20946$
"Patrick Brunet" <Patrick.Brunet @ cned.fr> nous disait
Tu connais le problème du carré de 9 points,
tu veux dire 9 points disposés en carré 3x3 ?
oui, c'est ça
Si je me souviens bien, il faut joindre les 9 points, sans lever le crayon et sans repasser deux fois au même endroit :
Sisi, dans l'énoncé nominal, il n'est pas interdit de repasser par un ou plusieurs points. En fait, c'est le contraire qui est difficile : passer par tous les points.
.-.-.- | / . . . | X . . . |/
(désolé pour la mauvaise qualité de l'ASCII-art)
C'est effectivement la bonne solution, mais ce qui est intéressant, c'est qu'elle nécessite de sortir du carré, et 8 personnes sur 10 (ne connaissant pas la solution) vont s'arracher les cheveux sans la trouver (essayez autour de vous). S'interdire de sortir d'un périmètre est une contrainte que l'on se donne soi-même instinctivement.
C'est ce qui motivait cette petite digression sur les réflexes pavloviens.
