Pb de Threads

Gabriel Dos Reis

27/11/2003 à 16:53

writes:

| Ce qui ne veut pas dire qu'une discussion sur les détails de l'API Posix
| peut avoir lieu ici.

lorsque c'est détails coupent des aspects de C++, je crois qu'elle
peut avoir lieu issue.

-- Gaby

kanze

28/11/2003 à 13:08

Gabriel Dos Reis wrote in message
news:...

writes:

| Ce qui ne veut pas dire qu'une discussion sur les détails de l'API
| Posix peut avoir lieu ici.

lorsque c'est détails coupent des aspects de C++, je crois qu'elle
peut avoir lieu issue.

Tout à fait.

Je serais tempté à dire que puisque Posix ignore le C++, le C++ doit
aussi ignorer Posix:-).

En fait (et la même chose vaut pour Windows, évidemment), je ne sais pas
où il faut faire la ligne exactement. Le problème, c'est souvent comment
la question se pose : comment faire pour récupérer le pointeur à une
fonction renvoyer par dlsym n'apparaît pas a priori sur le sujet --
jusqu'à ce qu'on sache que le vrai problème, c'est que Posix renvoie le
pointeur à une fonction dans un void*. C'est un peu comme les
programmeurs Windows qui essaient à passer l'adresse d'une fonction
membre comme callback (mais je crois que le même problème existe avec
X-windows) : son vrai problème, c'est bien le fait que les pointeurs à
membre ne sont pas des pointeurs tout courts.

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

--
James Kanze GABI Software mailto:
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

Gabriel Dos Reis

28/11/2003 à 13:57

writes:

| l'exprimer. Des questions du genre : que signifie l'int que renvoie
| pthread_create sont bien hors sujet.

je suis d'accord là-dessus.

-- Gaby

Jean-Marc Bourguet

28/11/2003 à 15:02

writes:

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

Ma limite a moi, c'est le langage. Si ca concerne le langage c'est en
theme meme si c'est dans le contexte d'une bibliotheque quelconque.
Pour eviter des problemes de s'avoir ou s'arrete le langage et ou
commence la bibliotheque standard, toute celle-ci fait partie du
langage pour fixer la limite.

Les demandes pour trouver une bibliotheque ou les comparaisons entre
bibliotheques sont aussi en theme.

Les questions sur l'utilisation d'une bibliotheque sont a priori hors
theme.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Cyrille Karmann

28/11/2003 à 16:53

Jean-Marc Bourguet disait...

writes:

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

Ma limite a moi, c'est le langage. Si ca concerne le langage c'est en
theme meme si c'est dans le contexte d'une bibliotheque quelconque.
Pour eviter des problemes de s'avoir ou s'arrete le langage et ou
commence la bibliotheque standard, toute celle-ci fait partie du
langage pour fixer la limite.

D'accord sauf pour:

Les demandes pour trouver une bibliotheque ou les comparaisons entre
bibliotheques sont aussi en theme.

Je pense que les discussions pour *trouver* une bibliothèque spécifique
à Windows devraient être sous fr.comp.os.ms-windows.programmation, et
celles pour les bibliothèques graphiques sous
fr.comp.graphisme.programmation...
Surtout les "comparaisons" entre bibliothèques... Remarquez moi je veux
bien, la prochaine fois qu'il y aura un débat foireux sur les mérites
respectifs d'OpenGL et DirectX, le rediriger sur fclc++! ;-)

Bef, la limite à poser n'est pas si simple, parce que je trouve toujours
que fclc++ est le meilleur endroit pour parler de boost, qui n'est
pourtant pas dans la bibliothèque standard.

Les questions sur l'utilisation d'une bibliotheque sont a priori hors
theme.

Oui.

--
Cyrille
Euro 2004: Santini delenda est.

James Kanze

29/11/2003 à 11:57

Jean-Marc Bourguet writes:

|> writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un point
c'est tout. Malheureusement, je ne trouve pas de telle limitation
réaliste ; si c'était le cas, ce groupe cesserait d'avoir un
intérêt réel pour moi, pour la simple raison que je ne peux pas
utiliser un compilateur conforme dans mon travail de tous les jours. De
l'autre part, comme beaucoup d'autres, je suis confronté à des
applications multi-thread, avec une édition de liens dynamique et les
communications avec d'autres systèmes ; même si ce n'est pas
actuellement mon cas, je conçois également que certains soient
confronté des problèmes d'interface graphique. Je n'exclurais pas
de discussions sur ces thèmes, dans la mésure que la discussion ne
s'adresse pas aux détails d'une interface donnée disponible que
sur un nombre de systèmes limité, et que ces détails ne
concernent pas des aspects du langage. (Et Posix et Windows ont parfois
des interactions avec le système de types de C++, ce qui fait qu'il y
a des questions bien propre à ces deux systèmes qui sont
acceptables ici.)

Il y a aussi la question des directions futures que pourrait prendre la
norme. Moi, en tout cas, je suis tout à pour permettre la discussion
Boost, par exemple, voire même d'autres bibliothèques dans la
mésure qu'elles ont une vocation « universelle ».

|> Les demandes pour trouver une bibliotheque ou les comparaisons entre
|> bibliotheques sont aussi en theme.

|> Les questions sur l'utilisation d'une bibliotheque sont a priori
|> hors theme.

Je ne suis pas si stricte. Comme j'ai dit, dans la mésure que de
telles bibliothèques prétendent être portable. Boost, par
exemple, ou autrefois ACE. Et à condition que cette prétention ne
soit pas sans une certaine fondamment -- ce n'est pas parce que l'auteur
de la bibliothèque reclaime l'universalité que la bibliothèque
a une universalité. (En fait, je ne crois pas que
« prétention » est le mot que je cherche.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> kanze@gabi-soft.fr writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un point
c'est tout. Malheureusement, je ne trouve pas de telle limitation
réaliste ; si c'était le cas, ce groupe cesserait d'avoir un
intérêt réel pour moi, pour la simple raison que je ne peux pas
utiliser un compilateur conforme dans mon travail de tous les jours. De
l'autre part, comme beaucoup d'autres, je suis confronté à des
applications multi-thread, avec une édition de liens dynamique et les
communications avec d'autres systèmes ; même si ce n'est pas
actuellement mon cas, je conçois également que certains soient
confronté des problèmes d'interface graphique. Je n'exclurais pas
de discussions sur ces thèmes, dans la mésure que la discussion ne
s'adresse pas aux détails d'une interface donnée disponible que
sur un nombre de systèmes limité, et que ces détails ne
concernent pas des aspects du langage. (Et Posix et Windows ont parfois
des interactions avec le système de types de C++, ce qui fait qu'il y
a des questions bien propre à ces deux systèmes qui sont
acceptables ici.)

Il y a aussi la question des directions futures que pourrait prendre la
norme. Moi, en tout cas, je suis tout à pour permettre la discussion
Boost, par exemple, voire même d'autres bibliothèques dans la
mésure qu'elles ont une vocation « universelle ».

|> Les demandes pour trouver une bibliotheque ou les comparaisons entre
|> bibliotheques sont aussi en theme.

|> Les questions sur l'utilisation d'une bibliotheque sont a priori
|> hors theme.

Je ne suis pas si stricte. Comme j'ai dit, dans la mésure que de
telles bibliothèques prétendent être portable. Boost, par
exemple, ou autrefois ACE. Et à condition que cette prétention ne
soit pas sans une certaine fondamment -- ce n'est pas parce que l'auteur
de la bibliothèque reclaime l'universalité que la bibliothèque
a une universalité. (En fait, je ne crois pas que
« prétention » est le mot que je cherche.)

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Bourguet writes:

|> writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un point
c'est tout. Malheureusement, je ne trouve pas de telle limitation
réaliste ; si c'était le cas, ce groupe cesserait d'avoir un
intérêt réel pour moi, pour la simple raison que je ne peux pas
utiliser un compilateur conforme dans mon travail de tous les jours. De
l'autre part, comme beaucoup d'autres, je suis confronté à des
applications multi-thread, avec une édition de liens dynamique et les
communications avec d'autres systèmes ; même si ce n'est pas
actuellement mon cas, je conçois également que certains soient
confronté des problèmes d'interface graphique. Je n'exclurais pas
de discussions sur ces thèmes, dans la mésure que la discussion ne
s'adresse pas aux détails d'une interface donnée disponible que
sur un nombre de systèmes limité, et que ces détails ne
concernent pas des aspects du langage. (Et Posix et Windows ont parfois
des interactions avec le système de types de C++, ce qui fait qu'il y
a des questions bien propre à ces deux systèmes qui sont
acceptables ici.)

Il y a aussi la question des directions futures que pourrait prendre la
norme. Moi, en tout cas, je suis tout à pour permettre la discussion
Boost, par exemple, voire même d'autres bibliothèques dans la
mésure qu'elles ont une vocation « universelle ».

|> Les demandes pour trouver une bibliotheque ou les comparaisons entre
|> bibliotheques sont aussi en theme.

|> Les questions sur l'utilisation d'une bibliotheque sont a priori
|> hors theme.

Je ne suis pas si stricte. Comme j'ai dit, dans la mésure que de
telles bibliothèques prétendent être portable. Boost, par
exemple, ou autrefois ACE. Et à condition que cette prétention ne
soit pas sans une certaine fondamment -- ce n'est pas parce que l'auteur
de la bibliothèque reclaime l'universalité que la bibliothèque
a une universalité. (En fait, je ne crois pas que
« prétention » est le mot que je cherche.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

James Kanze

29/11/2003 à 12:02

Cyrille Karmann writes:

|> Jean-Marc Bourguet disait...
|> > writes:

|> > > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > > que renvoie pthread_create sont bien hors sujet.

|> > Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> > en theme meme si c'est dans le contexte d'une bibliotheque
|> > quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> > langage et ou commence la bibliotheque standard, toute celle-ci
|> > fait partie du langage pour fixer la limite.

|> D'accord sauf pour:

|> > Les demandes pour trouver une bibliotheque ou les comparaisons
|> > entre bibliotheques sont aussi en theme.

|> Je pense que les discussions pour *trouver* une bibliothèque
|> spécifique à Windows devraient être sous
|> fr.comp.os.ms-windows.programmation, et celles pour les
|> bibliothèques graphiques sous fr.comp.graphisme.programmation...

La question, c'est peut-être est-ce qu'il y a un autre endroit qui
convient plus ? Dans le cas d'une bibliothèque spécifique sous
Windows, il y a effraction de ma règle d'universalité ; AMHA,
c'est sûr que c'est hors sujet. En ce qui concerne les
bibliothèques graphiques, je suis moins certains, mais ta suggestion
n'est pas sans valeur. Je crois qu'il y a un groupe pour les reseaux
aussi, en ce qui concerne la communication entre des machines, et au
moins en anglais, il y a un groupe spécifique pour les threads.

|> Surtout les "comparaisons" entre bibliothèques... Remarquez moi
|> je veux bien, la prochaine fois qu'il y aura un débat foireux sur
|> les mérites respectifs d'OpenGL et DirectX, le rediriger sur
|> fclc++! ;-)

|> Bef, la limite à poser n'est pas si simple, parce que je trouve
|> toujours que fclc++ est le meilleur endroit pour parler de boost,
|> qui n'est pourtant pas dans la bibliothèque standard.

Tout à fait d'accord. En revanche, est-ce ça vaut aussi pour des
bibliothèques générales comme OSE ou celle chez moi ? J'aurais
une tendance à dire non, mais la seule raison que je pourrais donner
pour accepter Boost, et rejeter Gabi Soft et OSE, c'est que Boost a
reçu une acceptance plus ou moins générale, ce qui n'est pas le
cas des autres deux. (Enfin, Gabi Soft l'a reçu indirectement, parce
qu'au moins de mes développements ont été répris par
d'autres pour Boost.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Cyrille Karmann <cyrille@frsf.org> writes:

|> Jean-Marc Bourguet disait...
|> > kanze@gabi-soft.fr writes:

|> > > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > > que renvoie pthread_create sont bien hors sujet.

|> > Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> > en theme meme si c'est dans le contexte d'une bibliotheque
|> > quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> > langage et ou commence la bibliotheque standard, toute celle-ci
|> > fait partie du langage pour fixer la limite.

|> D'accord sauf pour:

|> > Les demandes pour trouver une bibliotheque ou les comparaisons
|> > entre bibliotheques sont aussi en theme.

|> Je pense que les discussions pour *trouver* une bibliothèque
|> spécifique à Windows devraient être sous
|> fr.comp.os.ms-windows.programmation, et celles pour les
|> bibliothèques graphiques sous fr.comp.graphisme.programmation...

La question, c'est peut-être est-ce qu'il y a un autre endroit qui
convient plus ? Dans le cas d'une bibliothèque spécifique sous
Windows, il y a effraction de ma règle d'universalité ; AMHA,
c'est sûr que c'est hors sujet. En ce qui concerne les
bibliothèques graphiques, je suis moins certains, mais ta suggestion
n'est pas sans valeur. Je crois qu'il y a un groupe pour les reseaux
aussi, en ce qui concerne la communication entre des machines, et au
moins en anglais, il y a un groupe spécifique pour les threads.

|> Surtout les "comparaisons" entre bibliothèques... Remarquez moi
|> je veux bien, la prochaine fois qu'il y aura un débat foireux sur
|> les mérites respectifs d'OpenGL et DirectX, le rediriger sur
|> fclc++! ;-)

|> Bef, la limite à poser n'est pas si simple, parce que je trouve
|> toujours que fclc++ est le meilleur endroit pour parler de boost,
|> qui n'est pourtant pas dans la bibliothèque standard.

Tout à fait d'accord. En revanche, est-ce ça vaut aussi pour des
bibliothèques générales comme OSE ou celle chez moi ? J'aurais
une tendance à dire non, mais la seule raison que je pourrais donner
pour accepter Boost, et rejeter Gabi Soft et OSE, c'est que Boost a
reçu une acceptance plus ou moins générale, ce qui n'est pas le
cas des autres deux. (Enfin, Gabi Soft l'a reçu indirectement, parce
qu'au moins de mes développements ont été répris par
d'autres pour Boost.)

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Karmann writes:

|> Jean-Marc Bourguet disait...
|> > writes:

|> > > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > > que renvoie pthread_create sont bien hors sujet.

|> > Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> > en theme meme si c'est dans le contexte d'une bibliotheque
|> > quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> > langage et ou commence la bibliotheque standard, toute celle-ci
|> > fait partie du langage pour fixer la limite.

|> D'accord sauf pour:

|> > Les demandes pour trouver une bibliotheque ou les comparaisons
|> > entre bibliotheques sont aussi en theme.

|> Je pense que les discussions pour *trouver* une bibliothèque
|> spécifique à Windows devraient être sous
|> fr.comp.os.ms-windows.programmation, et celles pour les
|> bibliothèques graphiques sous fr.comp.graphisme.programmation...

La question, c'est peut-être est-ce qu'il y a un autre endroit qui
convient plus ? Dans le cas d'une bibliothèque spécifique sous
Windows, il y a effraction de ma règle d'universalité ; AMHA,
c'est sûr que c'est hors sujet. En ce qui concerne les
bibliothèques graphiques, je suis moins certains, mais ta suggestion
n'est pas sans valeur. Je crois qu'il y a un groupe pour les reseaux
aussi, en ce qui concerne la communication entre des machines, et au
moins en anglais, il y a un groupe spécifique pour les threads.

|> Surtout les "comparaisons" entre bibliothèques... Remarquez moi
|> je veux bien, la prochaine fois qu'il y aura un débat foireux sur
|> les mérites respectifs d'OpenGL et DirectX, le rediriger sur
|> fclc++! ;-)

|> Bef, la limite à poser n'est pas si simple, parce que je trouve
|> toujours que fclc++ est le meilleur endroit pour parler de boost,
|> qui n'est pourtant pas dans la bibliothèque standard.

Tout à fait d'accord. En revanche, est-ce ça vaut aussi pour des
bibliothèques générales comme OSE ou celle chez moi ? J'aurais
une tendance à dire non, mais la seule raison que je pourrais donner
pour accepter Boost, et rejeter Gabi Soft et OSE, c'est que Boost a
reçu une acceptance plus ou moins générale, ce qui n'est pas le
cas des autres deux. (Enfin, Gabi Soft l'a reçu indirectement, parce
qu'au moins de mes développements ont été répris par
d'autres pour Boost.)

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Jean-Marc Bourguet

30/11/2003 à 10:50

Cyrille Karmann writes:

Jean-Marc Bourguet disait...
writes:

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

Ma limite a moi, c'est le langage. Si ca concerne le langage c'est en
theme meme si c'est dans le contexte d'une bibliotheque quelconque.
Pour eviter des problemes de s'avoir ou s'arrete le langage et ou
commence la bibliotheque standard, toute celle-ci fait partie du
langage pour fixer la limite.

D'accord sauf pour:

Les demandes pour trouver une bibliotheque ou les comparaisons entre
bibliotheques sont aussi en theme.

Je pense que les discussions pour *trouver* une bibliothèque spécifique
à Windows devraient être sous fr.comp.os.ms-windows.programmation, et

Je ne crois pas qu'il y ait beaucoup de demande pour des bibliothèques
spécifiques Windows, de la demande pour des bibliothèques C++
fonctionnant sous Windows oui, mais dans ce cas sauf à connaître déjà
la réponse on ne sait pas si c'est spécifique à Windows ou pas.

celles pour les bibliothèques graphiques sous
fr.comp.graphisme.programmation...

Quand on cherche une bibliothèque C++ graphique, les deux groupes me
semblent tout aussi adapté.

Surtout les "comparaisons" entre bibliothèques... Remarquez moi je veux
bien, la prochaine fois qu'il y aura un débat foireux sur les mérites
respectifs d'OpenGL et DirectX, le rediriger sur fclc++! ;-)

S'il s'agit de l'aspect C++ des mérites, n'hésite pas. S'il s'agit de
l'aspect nombre de trames par seconde, effectivement il y a mieux.

Bef, la limite à poser n'est pas si simple, parce que je trouve
toujours que fclc++ est le meilleur endroit pour parler de boost,
qui n'est pourtant pas dans la bibliothèque standard.

"Il n'y a pas de meilleur groupe francophone pour discutter de ça"
n'est que rarement (fr.misc.divers, ...) une bonne raison pour
discutter de quelque chose sur un groupe.

Ce n'est pas parce que je ne vois pas de meilleur groupe francophone
que fclc++ pour discutter d'OpenAccess que je vais poser mes questions
sur cette bibliothèque ici. Mais à nouveau tout dépend de la
question, si c'est "Que pensez vous de l'idiome -- souvent utilisé
dans OpenAccess -- consistant à remplacer une fonction membre par une
fonction statique d'une autre classe tout en rendant cette classe amie
pour éviter de faire grossir l'interface de la première classe?",
effectivement fclc++ me semble adapté. Par contre "comment
déconnecter une instPin d'un net tout en laissant l'instTerm
correspondant connecté?", n'a rien à faire ici.

Boost est un peu particulier par l'intention d'en faire une
anti-chambre de la normalisation. Mais il y a des choses dedans
assurément non destinée à la normalisation (Spirit par exemple). Et
"Comment sortir des messages d'erreurs raisonnables avec Spirit?" ne
me semble pas en thème sur fclc++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Cyrille Karmann <cyrille@frsf.org> writes:

Jean-Marc Bourguet disait...

kanze@gabi-soft.fr writes:

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

Ma limite a moi, c'est le langage. Si ca concerne le langage c'est en
theme meme si c'est dans le contexte d'une bibliotheque quelconque.
Pour eviter des problemes de s'avoir ou s'arrete le langage et ou
commence la bibliotheque standard, toute celle-ci fait partie du
langage pour fixer la limite.

D'accord sauf pour:

Les demandes pour trouver une bibliotheque ou les comparaisons entre
bibliotheques sont aussi en theme.

Je pense que les discussions pour *trouver* une bibliothèque spécifique
à Windows devraient être sous fr.comp.os.ms-windows.programmation, et

Je ne crois pas qu'il y ait beaucoup de demande pour des bibliothèques
spécifiques Windows, de la demande pour des bibliothèques C++
fonctionnant sous Windows oui, mais dans ce cas sauf à connaître déjà
la réponse on ne sait pas si c'est spécifique à Windows ou pas.

celles pour les bibliothèques graphiques sous
fr.comp.graphisme.programmation...

Quand on cherche une bibliothèque C++ graphique, les deux groupes me
semblent tout aussi adapté.

Surtout les "comparaisons" entre bibliothèques... Remarquez moi je veux
bien, la prochaine fois qu'il y aura un débat foireux sur les mérites
respectifs d'OpenGL et DirectX, le rediriger sur fclc++! ;-)

S'il s'agit de l'aspect C++ des mérites, n'hésite pas. S'il s'agit de
l'aspect nombre de trames par seconde, effectivement il y a mieux.

Bef, la limite à poser n'est pas si simple, parce que je trouve
toujours que fclc++ est le meilleur endroit pour parler de boost,
qui n'est pourtant pas dans la bibliothèque standard.

"Il n'y a pas de meilleur groupe francophone pour discutter de ça"
n'est que rarement (fr.misc.divers, ...) une bonne raison pour
discutter de quelque chose sur un groupe.

Ce n'est pas parce que je ne vois pas de meilleur groupe francophone
que fclc++ pour discutter d'OpenAccess que je vais poser mes questions
sur cette bibliothèque ici. Mais à nouveau tout dépend de la
question, si c'est "Que pensez vous de l'idiome -- souvent utilisé
dans OpenAccess -- consistant à remplacer une fonction membre par une
fonction statique d'une autre classe tout en rendant cette classe amie
pour éviter de faire grossir l'interface de la première classe?",
effectivement fclc++ me semble adapté. Par contre "comment
déconnecter une instPin d'un net tout en laissant l'instTerm
correspondant connecté?", n'a rien à faire ici.

Boost est un peu particulier par l'intention d'en faire une
anti-chambre de la normalisation. Mais il y a des choses dedans
assurément non destinée à la normalisation (Spirit par exemple). Et
"Comment sortir des messages d'erreurs raisonnables avec Spirit?" ne
me semble pas en thème sur fclc++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

Cyrille Karmann writes:

Jean-Marc Bourguet disait...
writes:

Mais bon, je sais ce que je voulais dire, même si je ne sais pas bien
l'exprimer. Des questions du genre : que signifie l'int que renvoie
pthread_create sont bien hors sujet.

Ma limite a moi, c'est le langage. Si ca concerne le langage c'est en
theme meme si c'est dans le contexte d'une bibliotheque quelconque.
Pour eviter des problemes de s'avoir ou s'arrete le langage et ou
commence la bibliotheque standard, toute celle-ci fait partie du
langage pour fixer la limite.

D'accord sauf pour:

Les demandes pour trouver une bibliotheque ou les comparaisons entre
bibliotheques sont aussi en theme.

Je pense que les discussions pour *trouver* une bibliothèque spécifique
à Windows devraient être sous fr.comp.os.ms-windows.programmation, et

Je ne crois pas qu'il y ait beaucoup de demande pour des bibliothèques
spécifiques Windows, de la demande pour des bibliothèques C++
fonctionnant sous Windows oui, mais dans ce cas sauf à connaître déjà
la réponse on ne sait pas si c'est spécifique à Windows ou pas.

celles pour les bibliothèques graphiques sous
fr.comp.graphisme.programmation...

Quand on cherche une bibliothèque C++ graphique, les deux groupes me
semblent tout aussi adapté.

Surtout les "comparaisons" entre bibliothèques... Remarquez moi je veux
bien, la prochaine fois qu'il y aura un débat foireux sur les mérites
respectifs d'OpenGL et DirectX, le rediriger sur fclc++! ;-)

S'il s'agit de l'aspect C++ des mérites, n'hésite pas. S'il s'agit de
l'aspect nombre de trames par seconde, effectivement il y a mieux.

Bef, la limite à poser n'est pas si simple, parce que je trouve
toujours que fclc++ est le meilleur endroit pour parler de boost,
qui n'est pourtant pas dans la bibliothèque standard.

"Il n'y a pas de meilleur groupe francophone pour discutter de ça"
n'est que rarement (fr.misc.divers, ...) une bonne raison pour
discutter de quelque chose sur un groupe.

Ce n'est pas parce que je ne vois pas de meilleur groupe francophone
que fclc++ pour discutter d'OpenAccess que je vais poser mes questions
sur cette bibliothèque ici. Mais à nouveau tout dépend de la
question, si c'est "Que pensez vous de l'idiome -- souvent utilisé
dans OpenAccess -- consistant à remplacer une fonction membre par une
fonction statique d'une autre classe tout en rendant cette classe amie
pour éviter de faire grossir l'interface de la première classe?",
effectivement fclc++ me semble adapté. Par contre "comment
déconnecter une instPin d'un net tout en laissant l'instTerm
correspondant connecté?", n'a rien à faire ici.

Boost est un peu particulier par l'intention d'en faire une
anti-chambre de la normalisation. Mais il y a des choses dedans
assurément non destinée à la normalisation (Spirit par exemple). Et
"Comment sortir des messages d'erreurs raisonnables avec Spirit?" ne
me semble pas en thème sur fclc++.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Jean-Marc Bourguet

30/11/2003 à 11:45

James Kanze writes:

Jean-Marc Bourguet writes:

|> writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un
point c'est tout.

Je crois que tu sais bien que ce n'est pas mon point de vue. Le
premier intérêt d'une norme est la portabilité qu'elle apporte et donc
une norme ISO non implémentée a moins d'intérêt qu'un standard de fait
partout respecté.

Je n'exclurais pas de discussions sur ces thèmes [multi-threads,
bibliothèques dynamiques, communications, interface graphique], dans
la mésure que la discussion ne s'adresse pas aux détails d'une

s/mésure/mesure/ (tu fais souvent l'erreur)

interface donnée disponible que sur un nombre de systèmes limité, et
que ces détails ne concernent pas des aspects du langage.

Je ne vois pas bien quels aspects généraux tu veux discutter s'ils
n'ont pas d'interaction sur le langage.

Les deux premiers thèmes (multi-threads et bibliothèques dynamiques)
sont tellement liés avec le langage qu'y trouver des thèmes généraux
sans interaction m'est difficile.

Le troisième (communications) est suffisemment découplé pour qu'une
approche purement bibliothèque soit possible sans trop d'inconvéniant,
mais est quand même suffisemment proche pour qu'Ada ait préféré mettre
des choses dans le langage. Je vois donc des thèmes généraux propres
ce thème qui peuvent être en thème ici et d'autres non (l'intérêt pour
les implémentations hardware d'avoir le checksum placé en fin de trame
plutôt qu'au début et les conséquences sur les trames de longueur
variable par exemple).

Je connais très mal le quatrième (interface graphique), mais je ne
vois pas de sujets les concernant exclusivement que j'ai envie de
discutter ici.

Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup plus
d'indulgence pour les digressions et les changements de thèmes
progressifs d'une discussion que pour des questions initiales.

(Et Posix et Windows ont parfois des interactions avec le système de
types de C++, ce qui fait qu'il y a des questions bien propre à ces
deux systèmes qui sont acceptables ici.)

Le système de type fait partie du langage, donc j'ai vraiment pas de
problème à ce que ces thèmes soit abordés.

Il y a aussi la question des directions futures que pourrait prendre
la norme. Moi, en tout cas, je suis tout à pour permettre la
discussion Boost, par exemple, voire même d'autres bibliothèques
dans la mésure qu'elles ont une vocation « universelle ».

Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit me
semble moins en thème sur fclc++ que l'interaction des exceptions
systèmes de Windows avec les exceptions C++.

Les techniques de metaprogrammation utilisées dans Spirit sont tout à
fait en thème, mais ressortent du langage.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

James Kanze <kanze@alex.gabi-soft.fr> writes:

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> kanze@gabi-soft.fr writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un
point c'est tout.

Je crois que tu sais bien que ce n'est pas mon point de vue. Le
premier intérêt d'une norme est la portabilité qu'elle apporte et donc
une norme ISO non implémentée a moins d'intérêt qu'un standard de fait
partout respecté.

Je n'exclurais pas de discussions sur ces thèmes [multi-threads,
bibliothèques dynamiques, communications, interface graphique], dans
la mésure que la discussion ne s'adresse pas aux détails d'une

s/mésure/mesure/ (tu fais souvent l'erreur)

interface donnée disponible que sur un nombre de systèmes limité, et
que ces détails ne concernent pas des aspects du langage.

Je ne vois pas bien quels aspects généraux tu veux discutter s'ils
n'ont pas d'interaction sur le langage.

Les deux premiers thèmes (multi-threads et bibliothèques dynamiques)
sont tellement liés avec le langage qu'y trouver des thèmes généraux
sans interaction m'est difficile.

Le troisième (communications) est suffisemment découplé pour qu'une
approche purement bibliothèque soit possible sans trop d'inconvéniant,
mais est quand même suffisemment proche pour qu'Ada ait préféré mettre
des choses dans le langage. Je vois donc des thèmes généraux propres
ce thème qui peuvent être en thème ici et d'autres non (l'intérêt pour
les implémentations hardware d'avoir le checksum placé en fin de trame
plutôt qu'au début et les conséquences sur les trames de longueur
variable par exemple).

Je connais très mal le quatrième (interface graphique), mais je ne
vois pas de sujets les concernant exclusivement que j'ai envie de
discutter ici.

Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup plus
d'indulgence pour les digressions et les changements de thèmes
progressifs d'une discussion que pour des questions initiales.

(Et Posix et Windows ont parfois des interactions avec le système de
types de C++, ce qui fait qu'il y a des questions bien propre à ces
deux systèmes qui sont acceptables ici.)

Le système de type fait partie du langage, donc j'ai vraiment pas de
problème à ce que ces thèmes soit abordés.

Il y a aussi la question des directions futures que pourrait prendre
la norme. Moi, en tout cas, je suis tout à pour permettre la
discussion Boost, par exemple, voire même d'autres bibliothèques
dans la mésure qu'elles ont une vocation « universelle ».

Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit me
semble moins en thème sur fclc++ que l'interaction des exceptions
systèmes de Windows avec les exceptions C++.

Les techniques de metaprogrammation utilisées dans Spirit sont tout à
fait en thème, mais ressortent du langage.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze writes:

Jean-Marc Bourguet writes:

|> writes:

|> > Mais bon, je sais ce que je voulais dire, même si je ne sais
|> > pas bien l'exprimer. Des questions du genre : que signifie l'int
|> > que renvoie pthread_create sont bien hors sujet.

|> Ma limite a moi, c'est le langage. Si ca concerne le langage c'est
|> en theme meme si c'est dans le contexte d'une bibliotheque
|> quelconque. Pour eviter des problemes de s'avoir ou s'arrete le
|> langage et ou commence la bibliotheque standard, toute celle-ci fait
|> partie du langage pour fixer la limite.

Le problème, c'est aussi la définition du langage. J'ai parfois
l'impression que certains veulent le limiter à la norme ISO, un
point c'est tout.

Je crois que tu sais bien que ce n'est pas mon point de vue. Le
premier intérêt d'une norme est la portabilité qu'elle apporte et donc
une norme ISO non implémentée a moins d'intérêt qu'un standard de fait
partout respecté.

Je n'exclurais pas de discussions sur ces thèmes [multi-threads,
bibliothèques dynamiques, communications, interface graphique], dans
la mésure que la discussion ne s'adresse pas aux détails d'une

s/mésure/mesure/ (tu fais souvent l'erreur)

interface donnée disponible que sur un nombre de systèmes limité, et
que ces détails ne concernent pas des aspects du langage.

Je ne vois pas bien quels aspects généraux tu veux discutter s'ils
n'ont pas d'interaction sur le langage.

Les deux premiers thèmes (multi-threads et bibliothèques dynamiques)
sont tellement liés avec le langage qu'y trouver des thèmes généraux
sans interaction m'est difficile.

Le troisième (communications) est suffisemment découplé pour qu'une
approche purement bibliothèque soit possible sans trop d'inconvéniant,
mais est quand même suffisemment proche pour qu'Ada ait préféré mettre
des choses dans le langage. Je vois donc des thèmes généraux propres
ce thème qui peuvent être en thème ici et d'autres non (l'intérêt pour
les implémentations hardware d'avoir le checksum placé en fin de trame
plutôt qu'au début et les conséquences sur les trames de longueur
variable par exemple).

Je connais très mal le quatrième (interface graphique), mais je ne
vois pas de sujets les concernant exclusivement que j'ai envie de
discutter ici.

Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup plus
d'indulgence pour les digressions et les changements de thèmes
progressifs d'une discussion que pour des questions initiales.

(Et Posix et Windows ont parfois des interactions avec le système de
types de C++, ce qui fait qu'il y a des questions bien propre à ces
deux systèmes qui sont acceptables ici.)

Le système de type fait partie du langage, donc j'ai vraiment pas de
problème à ce que ces thèmes soit abordés.

Il y a aussi la question des directions futures que pourrait prendre
la norme. Moi, en tout cas, je suis tout à pour permettre la
discussion Boost, par exemple, voire même d'autres bibliothèques
dans la mésure qu'elles ont une vocation « universelle ».

Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit me
semble moins en thème sur fclc++ que l'interaction des exceptions
systèmes de Windows avec les exceptions C++.

Les techniques de metaprogrammation utilisées dans Spirit sont tout à
fait en thème, mais ressortent du langage.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

James Kanze

30/11/2003 à 12:44

Jean-Marc Bourguet writes:

|> James Kanze writes:

|> > Jean-Marc Bourguet writes:

|> > |> writes:

|> > |> > Mais bon, je sais ce que je voulais dire, même si je ne
|> > |> > sais pas bien l'exprimer. Des questions du genre : que
|> > |> > signifie l'int que renvoie pthread_create sont bien hors
|> > |> > sujet.

|> > |> Ma limite a moi, c'est le langage. Si ca concerne le langage
|> > |> c'est en theme meme si c'est dans le contexte d'une
|> > |> bibliotheque quelconque. Pour eviter des problemes de s'avoir
|> > |> ou s'arrete le langage et ou commence la bibliotheque
|> > |> standard, toute celle-ci fait partie du langage pour fixer la
|> > |> limite.

|> > Le problème, c'est aussi la définition du langage. J'ai
|> > parfois l'impression que certains veulent le limiter à la norme
|> > ISO, un point c'est tout.

|> Je crois que tu sais bien que ce n'est pas mon point de vue.

Tout à fait. Il ne m'était même pas venu à l'esprit qu'on
pouvait le penser. En général, je ne pensais qu'à ceux qui
s'acharne à crier hors-sujet pour n'importe quoi, sans vraiment
contribuer, au moins dans un sens positif, autrement.

|> Le premier intérêt d'une norme est la portabilité qu'elle
|> apporte et donc une norme ISO non implémentée a moins
|> d'intérêt qu'un standard de fait partout respecté.

C'est en effet le problème qui se pose actuellement. Pour l'instant,
on pourrait même dire que la situation est devenu pire à cause de
la norme : avant, il y avait un standard de fait en CFront. Mais d'une
part, cette situation n'aurait pas durée, même sans la norme, et
de l'autre, j'ai quand même l'espoir qu'avec le temps...

|> > Je n'exclurais pas de discussions sur ces thèmes
|> > [multi-threads, bibliothèques dynamiques, communications,
|> > interface graphique], dans la mésure que la discussion ne
|> > s'adresse pas aux détails d'une

|> s/mésure/mesure/ (tu fais souvent l'erreur)

Merci. C'est noté (ce qui ne veut pas dire que je ne ferais jamais
plus l'erreur:-)).

|> > interface donnée disponible que sur un nombre de systèmes
|> > limité, et que ces détails ne concernent pas des aspects du
|> > langage.

|> Je ne vois pas bien quels aspects généraux tu veux discutter
|> s'ils n'ont pas d'interaction sur le langage.

|> Les deux premiers thèmes (multi-threads et bibliothèques
|> dynamiques) sont tellement liés avec le langage qu'y trouver des
|> thèmes généraux sans interaction m'est difficile.

C'est à peu près mon avis. Discuter la signification exacte du
troisième paramètre de pthread_create, c'est hors sujet (au moins
que le problème tourne autour du type de ce paramètre, et ces
intéractions avec le typage C++), mais c'est à peu près tout ce
que je verrais hors sujet.

|> Le troisième (communications) est suffisemment découplé
|> pour qu'une approche purement bibliothèque soit possible sans
|> trop d'inconvéniant, mais est quand même suffisemment proche
|> pour qu'Ada ait préféré mettre des choses dans le langage.

C'est là où je suis moins sûr. Qu'est-ce que Ada met dans le
langage à cet égard ?

Disons que je crois qu'une discussion des aspects du protocol de niveau
5, 6 ou 7 serait hors-sujet ici. En ce qui concerne les 4 niveaux de
base aussi, mais il s'est apparamment fait un consensus que ces quatres
couches s'implémentent dans le système d'exploitation, et on
retombe donc parfois sur des problèmes des types utilisés dans
l'interface, ou des moyens de rendre le programme portable quand il fait
des choses qui ne sont pas couvertes par la norme.

|> Je vois donc des thèmes généraux propres ce thème qui
|> peuvent être en thème ici et d'autres non (l'intérêt
|> pour les implémentations hardware d'avoir le checksum placé en
|> fin de trame plutôt qu'au début et les conséquences sur les
|> trames de longueur variable par exemple).

Je suis curieux : est-ce que tu pourrais donner un exemple de ce qui
serait en thème ici ? Les seuls qui me vient à l'esprit sont des
questions de typage ou de sérialisation, ou de l'encapsulation des
dépendances système. Toutes questions tout à fait
indépendantes du protocol, quelqu'il soit.

|> Je connais très mal le quatrième (interface graphique), mais
|> je ne vois pas de sujets les concernant exclusivement que j'ai envie
|> de discutter ici.

Il y en a un, en tout cas : est-ce qu'une version future de la norme
doit s'adresser au problème ? :-)

|> Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup
|> plus d'indulgence pour les digressions et les changements de
|> thèmes progressifs d'une discussion que pour des questions
|> initiales.

Tout à fait. L'autre, c'est l'utilisation d'un système donné
à titre d'exemple d'un problème plus général. Dans mon cas,
le système en question serait toujours Posix, parce que c'est celui
que je connais le mieux, mais si Michel cite des particularités de
Windows dans une réponse plus générale, je n'ai rien contre.
(Au contraire -- dans les discussions sur les threads, j'aurais bien
aimé voir des exemples de ce qui est spécifié ailleurs que sous
Posix. Actuellement, je n'ai pas le moindre idée sur
l'universalité de ce que garantit Posix -- est-ce que tous les
systèmes sont à peu près pareils, ou est-ce qu'il y a des
différences importantes ?)

|> > (Et Posix et Windows ont parfois des interactions avec le
|> > système de types de C++, ce qui fait qu'il y a des questions
|> > bien propre à ces deux systèmes qui sont acceptables ici.)

|> Le système de type fait partie du langage, donc j'ai vraiment pas
|> de problème à ce que ces thèmes soit abordés.

Ma réponse ne te visait pas en particulière. J'essayais à faire
un synthèse de comment moi, je vois la question.

|> > Il y a aussi la question des directions futures que pourrait
|> > prendre la norme. Moi, en tout cas, je suis tout à pour
|> > permettre la discussion Boost, par exemple, voire même d'autres
|> > bibliothèques dans la mésure qu'elles ont une vocation
|> > « universelle ».

|> Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit
|> me semble moins en thème sur fclc++ que l'interaction des
|> exceptions systèmes de Windows avec les exceptions C++.

Peut-être. Je ne connais pas la gestion des erreurs dans Spirit ; je
ne peux donc pas juger. Mais les intérations entre les exceptions
systèmes de Windows et les exceptions C++ me semble tout à fait en
thème. Au moins dans la mesure qu'on ne descend pas aux détails de
l'interface système qui pourrait provoquer ou masquer telle ou telle
exception.

|> Les techniques de metaprogrammation utilisées dans Spirit sont
|> tout à fait en thème, mais ressortent du langage.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Jean-Marc Bourguet <jm@bourguet.org> writes:

|> James Kanze <kanze@alex.gabi-soft.fr> writes:

|> > Jean-Marc Bourguet <jm@bourguet.org> writes:

|> > |> kanze@gabi-soft.fr writes:

|> > |> > Mais bon, je sais ce que je voulais dire, même si je ne
|> > |> > sais pas bien l'exprimer. Des questions du genre : que
|> > |> > signifie l'int que renvoie pthread_create sont bien hors
|> > |> > sujet.

|> > |> Ma limite a moi, c'est le langage. Si ca concerne le langage
|> > |> c'est en theme meme si c'est dans le contexte d'une
|> > |> bibliotheque quelconque. Pour eviter des problemes de s'avoir
|> > |> ou s'arrete le langage et ou commence la bibliotheque
|> > |> standard, toute celle-ci fait partie du langage pour fixer la
|> > |> limite.

|> > Le problème, c'est aussi la définition du langage. J'ai
|> > parfois l'impression que certains veulent le limiter à la norme
|> > ISO, un point c'est tout.

|> Je crois que tu sais bien que ce n'est pas mon point de vue.

Tout à fait. Il ne m'était même pas venu à l'esprit qu'on
pouvait le penser. En général, je ne pensais qu'à ceux qui
s'acharne à crier hors-sujet pour n'importe quoi, sans vraiment
contribuer, au moins dans un sens positif, autrement.

|> Le premier intérêt d'une norme est la portabilité qu'elle
|> apporte et donc une norme ISO non implémentée a moins
|> d'intérêt qu'un standard de fait partout respecté.

C'est en effet le problème qui se pose actuellement. Pour l'instant,
on pourrait même dire que la situation est devenu pire à cause de
la norme : avant, il y avait un standard de fait en CFront. Mais d'une
part, cette situation n'aurait pas durée, même sans la norme, et
de l'autre, j'ai quand même l'espoir qu'avec le temps...

|> > Je n'exclurais pas de discussions sur ces thèmes
|> > [multi-threads, bibliothèques dynamiques, communications,
|> > interface graphique], dans la mésure que la discussion ne
|> > s'adresse pas aux détails d'une

|> s/mésure/mesure/ (tu fais souvent l'erreur)

Merci. C'est noté (ce qui ne veut pas dire que je ne ferais jamais
plus l'erreur:-)).

|> > interface donnée disponible que sur un nombre de systèmes
|> > limité, et que ces détails ne concernent pas des aspects du
|> > langage.

|> Je ne vois pas bien quels aspects généraux tu veux discutter
|> s'ils n'ont pas d'interaction sur le langage.

|> Les deux premiers thèmes (multi-threads et bibliothèques
|> dynamiques) sont tellement liés avec le langage qu'y trouver des
|> thèmes généraux sans interaction m'est difficile.

C'est à peu près mon avis. Discuter la signification exacte du
troisième paramètre de pthread_create, c'est hors sujet (au moins
que le problème tourne autour du type de ce paramètre, et ces
intéractions avec le typage C++), mais c'est à peu près tout ce
que je verrais hors sujet.

|> Le troisième (communications) est suffisemment découplé
|> pour qu'une approche purement bibliothèque soit possible sans
|> trop d'inconvéniant, mais est quand même suffisemment proche
|> pour qu'Ada ait préféré mettre des choses dans le langage.

C'est là où je suis moins sûr. Qu'est-ce que Ada met dans le
langage à cet égard ?

Disons que je crois qu'une discussion des aspects du protocol de niveau
5, 6 ou 7 serait hors-sujet ici. En ce qui concerne les 4 niveaux de
base aussi, mais il s'est apparamment fait un consensus que ces quatres
couches s'implémentent dans le système d'exploitation, et on
retombe donc parfois sur des problèmes des types utilisés dans
l'interface, ou des moyens de rendre le programme portable quand il fait
des choses qui ne sont pas couvertes par la norme.

|> Je vois donc des thèmes généraux propres ce thème qui
|> peuvent être en thème ici et d'autres non (l'intérêt
|> pour les implémentations hardware d'avoir le checksum placé en
|> fin de trame plutôt qu'au début et les conséquences sur les
|> trames de longueur variable par exemple).

Je suis curieux : est-ce que tu pourrais donner un exemple de ce qui
serait en thème ici ? Les seuls qui me vient à l'esprit sont des
questions de typage ou de sérialisation, ou de l'encapsulation des
dépendances système. Toutes questions tout à fait
indépendantes du protocol, quelqu'il soit.

|> Je connais très mal le quatrième (interface graphique), mais
|> je ne vois pas de sujets les concernant exclusivement que j'ai envie
|> de discutter ici.

Il y en a un, en tout cas : est-ce qu'une version future de la norme
doit s'adresser au problème ? :-)

|> Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup
|> plus d'indulgence pour les digressions et les changements de
|> thèmes progressifs d'une discussion que pour des questions
|> initiales.

Tout à fait. L'autre, c'est l'utilisation d'un système donné
à titre d'exemple d'un problème plus général. Dans mon cas,
le système en question serait toujours Posix, parce que c'est celui
que je connais le mieux, mais si Michel cite des particularités de
Windows dans une réponse plus générale, je n'ai rien contre.
(Au contraire -- dans les discussions sur les threads, j'aurais bien
aimé voir des exemples de ce qui est spécifié ailleurs que sous
Posix. Actuellement, je n'ai pas le moindre idée sur
l'universalité de ce que garantit Posix -- est-ce que tous les
systèmes sont à peu près pareils, ou est-ce qu'il y a des
différences importantes ?)

|> > (Et Posix et Windows ont parfois des interactions avec le
|> > système de types de C++, ce qui fait qu'il y a des questions
|> > bien propre à ces deux systèmes qui sont acceptables ici.)

|> Le système de type fait partie du langage, donc j'ai vraiment pas
|> de problème à ce que ces thèmes soit abordés.

Ma réponse ne te visait pas en particulière. J'essayais à faire
un synthèse de comment moi, je vois la question.

|> > Il y a aussi la question des directions futures que pourrait
|> > prendre la norme. Moi, en tout cas, je suis tout à pour
|> > permettre la discussion Boost, par exemple, voire même d'autres
|> > bibliothèques dans la mésure qu'elles ont une vocation
|> > « universelle ».

|> Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit
|> me semble moins en thème sur fclc++ que l'interaction des
|> exceptions systèmes de Windows avec les exceptions C++.

Peut-être. Je ne connais pas la gestion des erreurs dans Spirit ; je
ne peux donc pas juger. Mais les intérations entre les exceptions
systèmes de Windows et les exceptions C++ me semble tout à fait en
thème. Au moins dans la mesure qu'on ne descend pas aux détails de
l'interface système qui pourrait provoquer ou masquer telle ou telle
exception.

|> Les techniques de metaprogrammation utilisées dans Spirit sont
|> tout à fait en thème, mais ressortent du langage.

--
James Kanze mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Bourguet writes:

|> James Kanze writes:

|> > Jean-Marc Bourguet writes:

|> > |> writes:

|> > |> > Mais bon, je sais ce que je voulais dire, même si je ne
|> > |> > sais pas bien l'exprimer. Des questions du genre : que
|> > |> > signifie l'int que renvoie pthread_create sont bien hors
|> > |> > sujet.

|> > |> Ma limite a moi, c'est le langage. Si ca concerne le langage
|> > |> c'est en theme meme si c'est dans le contexte d'une
|> > |> bibliotheque quelconque. Pour eviter des problemes de s'avoir
|> > |> ou s'arrete le langage et ou commence la bibliotheque
|> > |> standard, toute celle-ci fait partie du langage pour fixer la
|> > |> limite.

|> > Le problème, c'est aussi la définition du langage. J'ai
|> > parfois l'impression que certains veulent le limiter à la norme
|> > ISO, un point c'est tout.

|> Je crois que tu sais bien que ce n'est pas mon point de vue.

Tout à fait. Il ne m'était même pas venu à l'esprit qu'on
pouvait le penser. En général, je ne pensais qu'à ceux qui
s'acharne à crier hors-sujet pour n'importe quoi, sans vraiment
contribuer, au moins dans un sens positif, autrement.

|> Le premier intérêt d'une norme est la portabilité qu'elle
|> apporte et donc une norme ISO non implémentée a moins
|> d'intérêt qu'un standard de fait partout respecté.

C'est en effet le problème qui se pose actuellement. Pour l'instant,
on pourrait même dire que la situation est devenu pire à cause de
la norme : avant, il y avait un standard de fait en CFront. Mais d'une
part, cette situation n'aurait pas durée, même sans la norme, et
de l'autre, j'ai quand même l'espoir qu'avec le temps...

|> > Je n'exclurais pas de discussions sur ces thèmes
|> > [multi-threads, bibliothèques dynamiques, communications,
|> > interface graphique], dans la mésure que la discussion ne
|> > s'adresse pas aux détails d'une

|> s/mésure/mesure/ (tu fais souvent l'erreur)

Merci. C'est noté (ce qui ne veut pas dire que je ne ferais jamais
plus l'erreur:-)).

|> > interface donnée disponible que sur un nombre de systèmes
|> > limité, et que ces détails ne concernent pas des aspects du
|> > langage.

|> Je ne vois pas bien quels aspects généraux tu veux discutter
|> s'ils n'ont pas d'interaction sur le langage.

|> Les deux premiers thèmes (multi-threads et bibliothèques
|> dynamiques) sont tellement liés avec le langage qu'y trouver des
|> thèmes généraux sans interaction m'est difficile.

C'est à peu près mon avis. Discuter la signification exacte du
troisième paramètre de pthread_create, c'est hors sujet (au moins
que le problème tourne autour du type de ce paramètre, et ces
intéractions avec le typage C++), mais c'est à peu près tout ce
que je verrais hors sujet.

|> Le troisième (communications) est suffisemment découplé
|> pour qu'une approche purement bibliothèque soit possible sans
|> trop d'inconvéniant, mais est quand même suffisemment proche
|> pour qu'Ada ait préféré mettre des choses dans le langage.

C'est là où je suis moins sûr. Qu'est-ce que Ada met dans le
langage à cet égard ?

Disons que je crois qu'une discussion des aspects du protocol de niveau
5, 6 ou 7 serait hors-sujet ici. En ce qui concerne les 4 niveaux de
base aussi, mais il s'est apparamment fait un consensus que ces quatres
couches s'implémentent dans le système d'exploitation, et on
retombe donc parfois sur des problèmes des types utilisés dans
l'interface, ou des moyens de rendre le programme portable quand il fait
des choses qui ne sont pas couvertes par la norme.

|> Je vois donc des thèmes généraux propres ce thème qui
|> peuvent être en thème ici et d'autres non (l'intérêt
|> pour les implémentations hardware d'avoir le checksum placé en
|> fin de trame plutôt qu'au début et les conséquences sur les
|> trames de longueur variable par exemple).

Je suis curieux : est-ce que tu pourrais donner un exemple de ce qui
serait en thème ici ? Les seuls qui me vient à l'esprit sont des
questions de typage ou de sérialisation, ou de l'encapsulation des
dépendances système. Toutes questions tout à fait
indépendantes du protocol, quelqu'il soit.

|> Je connais très mal le quatrième (interface graphique), mais
|> je ne vois pas de sujets les concernant exclusivement que j'ai envie
|> de discutter ici.

Il y en a un, en tout cas : est-ce qu'une version future de la norme
doit s'adresser au problème ? :-)

|> Quelque chose qui n'a pas été cité, c'est que j'ai beaucoup
|> plus d'indulgence pour les digressions et les changements de
|> thèmes progressifs d'une discussion que pour des questions
|> initiales.

Tout à fait. L'autre, c'est l'utilisation d'un système donné
à titre d'exemple d'un problème plus général. Dans mon cas,
le système en question serait toujours Posix, parce que c'est celui
que je connais le mieux, mais si Michel cite des particularités de
Windows dans une réponse plus générale, je n'ai rien contre.
(Au contraire -- dans les discussions sur les threads, j'aurais bien
aimé voir des exemples de ce qui est spécifié ailleurs que sous
Posix. Actuellement, je n'ai pas le moindre idée sur
l'universalité de ce que garantit Posix -- est-ce que tous les
systèmes sont à peu près pareils, ou est-ce qu'il y a des
différences importantes ?)

|> > (Et Posix et Windows ont parfois des interactions avec le
|> > système de types de C++, ce qui fait qu'il y a des questions
|> > bien propre à ces deux systèmes qui sont acceptables ici.)

|> Le système de type fait partie du langage, donc j'ai vraiment pas
|> de problème à ce que ces thèmes soit abordés.

Ma réponse ne te visait pas en particulière. J'essayais à faire
un synthèse de comment moi, je vois la question.

|> > Il y a aussi la question des directions futures que pourrait
|> > prendre la norme. Moi, en tout cas, je suis tout à pour
|> > permettre la discussion Boost, par exemple, voire même d'autres
|> > bibliothèques dans la mésure qu'elles ont une vocation
|> > « universelle ».

|> Comme je l'ai écrit ailleurs, la gestion des erreurs dans Spirit
|> me semble moins en thème sur fclc++ que l'interaction des
|> exceptions systèmes de Windows avec les exceptions C++.

Peut-être. Je ne connais pas la gestion des erreurs dans Spirit ; je
ne peux donc pas juger. Mais les intérations entre les exceptions
systèmes de Windows et les exceptions C++ me semble tout à fait en
thème. Au moins dans la mesure qu'on ne descend pas aux détails de
l'interface système qui pourrait provoquer ou masquer telle ou telle
exception.

|> Les techniques de metaprogrammation utilisées dans Spirit sont
|> tout à fait en thème, mais ressortent du langage.

--
James Kanze mailto:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France +33 1 41 89 80 93

Pb de Threads

10 réponses

Veuillez sélectionner un problème