Marc Boyer writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >| Ta question était ironique, ou moqueuse.
| >
| > Non. C'était une question pour aider à trouver une logique dans ton
| > argumentation.
|
| Quelle logique ?
J'avais supposé que ton argumentation avait une logique sous-jacente.
Mais s'il n'y a pas alors je comprends mieux.
| Que quand j'ai écris que je pensais
| que c'était une mauvaise idée d'avoir une GUI en C++,
| j'avais un avis différent de celui de BS, et que ça
| devait me faire revoir mes arguments ? Oui,
| sans aucun doute.
Là je ne te suis plus. D'abord, il n'y a aucune obligation à être
d'accord avec tout ce que dit BS.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >| Ta question était ironique, ou moqueuse.
| >
| > Non. C'était une question pour aider à trouver une logique dans ton
| > argumentation.
|
| Quelle logique ?
J'avais supposé que ton argumentation avait une logique sous-jacente.
Mais s'il n'y a pas alors je comprends mieux.
| Que quand j'ai écris que je pensais
| que c'était une mauvaise idée d'avoir une GUI en C++,
| j'avais un avis différent de celui de BS, et que ça
| devait me faire revoir mes arguments ? Oui,
| sans aucun doute.
Là je ne te suis plus. D'abord, il n'y a aucune obligation à être
d'accord avec tout ce que dit BS.
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer writes:
| >| Ta question était ironique, ou moqueuse.
| >
| > Non. C'était une question pour aider à trouver une logique dans ton
| > argumentation.
|
| Quelle logique ?
J'avais supposé que ton argumentation avait une logique sous-jacente.
Mais s'il n'y a pas alors je comprends mieux.
| Que quand j'ai écris que je pensais
| que c'était une mauvaise idée d'avoir une GUI en C++,
| j'avais un avis différent de celui de BS, et que ça
| devait me faire revoir mes arguments ? Oui,
| sans aucun doute.
Là je ne te suis plus. D'abord, il n'y a aucune obligation à être
d'accord avec tout ce que dit BS.
Marc Boyer writes:
| Il me semblait (impression, subjective) que C++
| s'était centré sur la partie "calcul", en se donnant
| des interfaces minimales d'entrée/sortie (flux)
| et la possibilité de se lier avec d'autres codes (extern).
C++ a été conçu comme un outil (qui se trouve être un langage de
programmation), mais surtout un outil pragmatique. En particulier, il
n'y a pas une distinction académique religieuse entre bibliothèque et
« core language ».
| Voilà, je suis surpris (en fait, j'étais quand tu m'as
| donné la ref à la FAQ de BS, maintenant, la surprise est
| passée) de voir apparaître un intérêt plus spécifique
| pour les GUI (1) que pour les répertoires, les bases de
| donnée ou les connexions réseaux.
Si tu penses que les connexions réseaux posent un problème qui doit
être résolu, soumets une proposition (cela demande un investissement)
ou fait une suggestion (cela ne coûte rien).
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Il me semblait (impression, subjective) que C++
| s'était centré sur la partie "calcul", en se donnant
| des interfaces minimales d'entrée/sortie (flux)
| et la possibilité de se lier avec d'autres codes (extern).
C++ a été conçu comme un outil (qui se trouve être un langage de
programmation), mais surtout un outil pragmatique. En particulier, il
n'y a pas une distinction académique religieuse entre bibliothèque et
« core language ».
| Voilà, je suis surpris (en fait, j'étais quand tu m'as
| donné la ref à la FAQ de BS, maintenant, la surprise est
| passée) de voir apparaître un intérêt plus spécifique
| pour les GUI (1) que pour les répertoires, les bases de
| donnée ou les connexions réseaux.
Si tu penses que les connexions réseaux posent un problème qui doit
être résolu, soumets une proposition (cela demande un investissement)
ou fait une suggestion (cela ne coûte rien).
Marc Boyer writes:
| Il me semblait (impression, subjective) que C++
| s'était centré sur la partie "calcul", en se donnant
| des interfaces minimales d'entrée/sortie (flux)
| et la possibilité de se lier avec d'autres codes (extern).
C++ a été conçu comme un outil (qui se trouve être un langage de
programmation), mais surtout un outil pragmatique. En particulier, il
n'y a pas une distinction académique religieuse entre bibliothèque et
« core language ».
| Voilà, je suis surpris (en fait, j'étais quand tu m'as
| donné la ref à la FAQ de BS, maintenant, la surprise est
| passée) de voir apparaître un intérêt plus spécifique
| pour les GUI (1) que pour les répertoires, les bases de
| donnée ou les connexions réseaux.
Si tu penses que les connexions réseaux posent un problème qui doit
être résolu, soumets une proposition (cela demande un investissement)
ou fait une suggestion (cela ne coûte rien).
Marc Boyer writes:
| Néanmoins, que le code d'implémentation ne soit
| par portable me semble rendre plus difficile la réalisation
| de compilateur multiplateforme. Non ?
La norme ne requiert pas un compilateur multiplateforme, ne dit pas
comment un tel compilateur doit être implémenté, ni que la
bibliothèque standard soit écrit en C++, et a fortiori que son code
d'implémentation soit portable. Donc, que le code d'implémentation
soit portable ou non importe peu.
Veux-tu banir le support des fichiers au prétexte que son code
d'implémentation n'est pas portable ?
On ne met pas quelque chose dans la bibliothèque standard juste parce
que son code d'implémentation est portable. En fait, un argument
sérieux pour mettre quelque chose dans la bibliothèque, c'est
justement parce que son code d'implémentation n'est pas portable.
Je crois que tu as mis les choses à l'envers.
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Néanmoins, que le code d'implémentation ne soit
| par portable me semble rendre plus difficile la réalisation
| de compilateur multiplateforme. Non ?
La norme ne requiert pas un compilateur multiplateforme, ne dit pas
comment un tel compilateur doit être implémenté, ni que la
bibliothèque standard soit écrit en C++, et a fortiori que son code
d'implémentation soit portable. Donc, que le code d'implémentation
soit portable ou non importe peu.
Veux-tu banir le support des fichiers au prétexte que son code
d'implémentation n'est pas portable ?
On ne met pas quelque chose dans la bibliothèque standard juste parce
que son code d'implémentation est portable. En fait, un argument
sérieux pour mettre quelque chose dans la bibliothèque, c'est
justement parce que son code d'implémentation n'est pas portable.
Je crois que tu as mis les choses à l'envers.
Marc Boyer writes:
| Néanmoins, que le code d'implémentation ne soit
| par portable me semble rendre plus difficile la réalisation
| de compilateur multiplateforme. Non ?
La norme ne requiert pas un compilateur multiplateforme, ne dit pas
comment un tel compilateur doit être implémenté, ni que la
bibliothèque standard soit écrit en C++, et a fortiori que son code
d'implémentation soit portable. Donc, que le code d'implémentation
soit portable ou non importe peu.
Veux-tu banir le support des fichiers au prétexte que son code
d'implémentation n'est pas portable ?
On ne met pas quelque chose dans la bibliothèque standard juste parce
que son code d'implémentation est portable. En fait, un argument
sérieux pour mettre quelque chose dans la bibliothèque, c'est
justement parce que son code d'implémentation n'est pas portable.
Je crois que tu as mis les choses à l'envers.
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| Ah... Non, disons que dans mon point de vue, s'il est
| vital pour moi de boire dans les 48h qui viennent, cela
| ne m'empèche pas pour le moment de taper sur fclc++
| (mais ça me donner soif d'en parler).
Moi non plus, mais je boirai *avant* de taper sur fclc++ -- surtout je
dois m'éterniser avec toi ;-/
| J'ajoute que j'ai aussi écrit "je pense que C++
| actuellement résoud les problèmes que j'évoquais"
| (qui étaient les problèmes "vitaux") et que la liste
| que j'ai faite était celle "des choses qui manquent
| actuellement à C++:" (dont aucun n'est vital, puisque
| C++ vit visiblement assez bien).
Donc, fianlement, tu ne sais plus où tu en es. Vitaux or not vitaux,
that is the question. C'est ça ?
| >| Actuellement, on travaille avec des #include,
| >| il faut se protéger contre les doubles inclusions,
| >| faire attention au nommage des gardes, tout ça.
| >| Dans mon souvenir, en Ada ou Pascal, c'est le
| >| langage qui gère.
| >
| > Je connais relativement bien Pascal, et le langage n'est pas
| > télépathique ; donc, quand tu dis que c'est le langage qui gère, le
| > programmeur fait quelque chose. Aussi, ce que ces langages gèrent
| > a-t-il quelque chose à avoir avec C++ ? Ce n'est pas une question de
| > rhétorique.
|
| Oui, le programmeur dit que telle portion de code
| fait partie d'une unité, et fait partie de son interface
| ou de son implémentation. Il peut aussi écrire un
| programme (la distinction me semble pas forcément
| pertinente).
| Il utilise des directives d'utilisation (uses) et le
| compilateur comprend tout seul qu'il lui faut l'interface
| il gère les doubles inclusions, tout ça.
|
| Il me semble que cette structuration en module
| existe dans beaucoup de programmes C++, ou l'on
| met ce que l'on considère "interface" dans un .h[pp]
| et implémentation dans un .cpp.
Il est exact que cette structuration existe en pratique en C++ -- et
des tonnes de littératures sont consacrées à ça. Mais ce n'est pas ce
que j'appellerai module ; et de fait, si c'en était une tu ne
demanderais pas que C++ résolve ce « problème ».
| Que cette notion entre dans le langage pourrait
Cette notion est déjà dans le langage. Donc, si je suppose que tu
parles de quelque chose d'autre. Il est difficile de savoir quoi tant
que tu n'as pas précisé (et non, ce n'est pas la phase de proposition).
| éventuellement obliger (ou signaler) à n'avoir que
| des déclarations de variable (et pas de définition)
| dans l'interface, ce genre de chose.
| On pourrait même envisager que la question des
| codes templates ou inline, qu'actuellement on importe
| avec #include, soit gérée par le compilateur qui,
Un code template n'est pas obligé d'être importé par #include.
Il existe un méchanisme dans le langage appelé « export ».
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| Gabriel Dos Reis wrote:
| Ah... Non, disons que dans mon point de vue, s'il est
| vital pour moi de boire dans les 48h qui viennent, cela
| ne m'empèche pas pour le moment de taper sur fclc++
| (mais ça me donner soif d'en parler).
Moi non plus, mais je boirai *avant* de taper sur fclc++ -- surtout je
dois m'éterniser avec toi ;-/
| J'ajoute que j'ai aussi écrit "je pense que C++
| actuellement résoud les problèmes que j'évoquais"
| (qui étaient les problèmes "vitaux") et que la liste
| que j'ai faite était celle "des choses qui manquent
| actuellement à C++:" (dont aucun n'est vital, puisque
| C++ vit visiblement assez bien).
Donc, fianlement, tu ne sais plus où tu en es. Vitaux or not vitaux,
that is the question. C'est ça ?
| >| Actuellement, on travaille avec des #include,
| >| il faut se protéger contre les doubles inclusions,
| >| faire attention au nommage des gardes, tout ça.
| >| Dans mon souvenir, en Ada ou Pascal, c'est le
| >| langage qui gère.
| >
| > Je connais relativement bien Pascal, et le langage n'est pas
| > télépathique ; donc, quand tu dis que c'est le langage qui gère, le
| > programmeur fait quelque chose. Aussi, ce que ces langages gèrent
| > a-t-il quelque chose à avoir avec C++ ? Ce n'est pas une question de
| > rhétorique.
|
| Oui, le programmeur dit que telle portion de code
| fait partie d'une unité, et fait partie de son interface
| ou de son implémentation. Il peut aussi écrire un
| programme (la distinction me semble pas forcément
| pertinente).
| Il utilise des directives d'utilisation (uses) et le
| compilateur comprend tout seul qu'il lui faut l'interface
| il gère les doubles inclusions, tout ça.
|
| Il me semble que cette structuration en module
| existe dans beaucoup de programmes C++, ou l'on
| met ce que l'on considère "interface" dans un .h[pp]
| et implémentation dans un .cpp.
Il est exact que cette structuration existe en pratique en C++ -- et
des tonnes de littératures sont consacrées à ça. Mais ce n'est pas ce
que j'appellerai module ; et de fait, si c'en était une tu ne
demanderais pas que C++ résolve ce « problème ».
| Que cette notion entre dans le langage pourrait
Cette notion est déjà dans le langage. Donc, si je suppose que tu
parles de quelque chose d'autre. Il est difficile de savoir quoi tant
que tu n'as pas précisé (et non, ce n'est pas la phase de proposition).
| éventuellement obliger (ou signaler) à n'avoir que
| des déclarations de variable (et pas de définition)
| dans l'interface, ce genre de chose.
| On pourrait même envisager que la question des
| codes templates ou inline, qu'actuellement on importe
| avec #include, soit gérée par le compilateur qui,
Un code template n'est pas obligé d'être importé par #include.
Il existe un méchanisme dans le langage appelé « export ».
Marc Boyer writes:
| Gabriel Dos Reis wrote:
| Ah... Non, disons que dans mon point de vue, s'il est
| vital pour moi de boire dans les 48h qui viennent, cela
| ne m'empèche pas pour le moment de taper sur fclc++
| (mais ça me donner soif d'en parler).
Moi non plus, mais je boirai *avant* de taper sur fclc++ -- surtout je
dois m'éterniser avec toi ;-/
| J'ajoute que j'ai aussi écrit "je pense que C++
| actuellement résoud les problèmes que j'évoquais"
| (qui étaient les problèmes "vitaux") et que la liste
| que j'ai faite était celle "des choses qui manquent
| actuellement à C++:" (dont aucun n'est vital, puisque
| C++ vit visiblement assez bien).
Donc, fianlement, tu ne sais plus où tu en es. Vitaux or not vitaux,
that is the question. C'est ça ?
| >| Actuellement, on travaille avec des #include,
| >| il faut se protéger contre les doubles inclusions,
| >| faire attention au nommage des gardes, tout ça.
| >| Dans mon souvenir, en Ada ou Pascal, c'est le
| >| langage qui gère.
| >
| > Je connais relativement bien Pascal, et le langage n'est pas
| > télépathique ; donc, quand tu dis que c'est le langage qui gère, le
| > programmeur fait quelque chose. Aussi, ce que ces langages gèrent
| > a-t-il quelque chose à avoir avec C++ ? Ce n'est pas une question de
| > rhétorique.
|
| Oui, le programmeur dit que telle portion de code
| fait partie d'une unité, et fait partie de son interface
| ou de son implémentation. Il peut aussi écrire un
| programme (la distinction me semble pas forcément
| pertinente).
| Il utilise des directives d'utilisation (uses) et le
| compilateur comprend tout seul qu'il lui faut l'interface
| il gère les doubles inclusions, tout ça.
|
| Il me semble que cette structuration en module
| existe dans beaucoup de programmes C++, ou l'on
| met ce que l'on considère "interface" dans un .h[pp]
| et implémentation dans un .cpp.
Il est exact que cette structuration existe en pratique en C++ -- et
des tonnes de littératures sont consacrées à ça. Mais ce n'est pas ce
que j'appellerai module ; et de fait, si c'en était une tu ne
demanderais pas que C++ résolve ce « problème ».
| Que cette notion entre dans le langage pourrait
Cette notion est déjà dans le langage. Donc, si je suppose que tu
parles de quelque chose d'autre. Il est difficile de savoir quoi tant
que tu n'as pas précisé (et non, ce n'est pas la phase de proposition).
| éventuellement obliger (ou signaler) à n'avoir que
| des déclarations de variable (et pas de définition)
| dans l'interface, ce genre de chose.
| On pourrait même envisager que la question des
| codes templates ou inline, qu'actuellement on importe
| avec #include, soit gérée par le compilateur qui,
Un code template n'est pas obligé d'être importé par #include.
Il existe un méchanisme dans le langage appelé « export ».
Plus concrêtement, qu'appelles-tu module avec
interface/implémentation ?
Etre plus concret, c'est déjà avancer vers une
proposition.
Actuellement, on travaille avec des #include,
il faut se protéger contre les doubles inclusions,
faire attention au nommage des gardes, tout ça.
Dans mon souvenir, en Ada ou Pascal, c'est le
langage qui gère.
Plus concrêtement, qu'appelles-tu module avec
interface/implémentation ?
Etre plus concret, c'est déjà avancer vers une
proposition.
Actuellement, on travaille avec des #include,
il faut se protéger contre les doubles inclusions,
faire attention au nommage des gardes, tout ça.
Dans mon souvenir, en Ada ou Pascal, c'est le
langage qui gère.
Plus concrêtement, qu'appelles-tu module avec
interface/implémentation ?
Etre plus concret, c'est déjà avancer vers une
proposition.
Actuellement, on travaille avec des #include,
il faut se protéger contre les doubles inclusions,
faire attention au nommage des gardes, tout ça.
Dans mon souvenir, en Ada ou Pascal, c'est le
langage qui gère.
bonjour1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose.
cela leur derait perdre leur temps parceque pour toi c'est peu important
cette parti
pour d'autres c'est tres important
et ce raisonnement tu peux le faire pour quasiment tout developpement,
donc on gele definitivement le c++ :(Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement.
pourquoi alors c'est possible dans la plupart des autres langages ?
java, tcl, python, etc marchent multi plateforme ! pourquoi le cpp
serait plus bloque qu'eux???
Heu... En ce qui concerne Python, je veux bien que tu me dises quel GUI
bonjour
1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose.
cela leur derait perdre leur temps parceque pour toi c'est peu important
cette parti
pour d'autres c'est tres important
et ce raisonnement tu peux le faire pour quasiment tout developpement,
donc on gele definitivement le c++ :(
Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement.
pourquoi alors c'est possible dans la plupart des autres langages ?
java, tcl, python, etc marchent multi plateforme ! pourquoi le cpp
serait plus bloque qu'eux???
Heu... En ce qui concerne Python, je veux bien que tu me dises quel GUI
bonjour1) elle obligerait les gens qui veulent faire un compilateur
conforme à implémenter cette GUI, ce qui leur ferait perdre du
temps, qui ne serait pas passé à autre chose.
cela leur derait perdre leur temps parceque pour toi c'est peu important
cette parti
pour d'autres c'est tres important
et ce raisonnement tu peux le faire pour quasiment tout developpement,
donc on gele definitivement le c++ :(Si en plus on
désire écrire un compilateur multi-plateforme (genre g++),
on plombe tout le développement.
pourquoi alors c'est possible dans la plupart des autres langages ?
java, tcl, python, etc marchent multi plateforme ! pourquoi le cpp
serait plus bloque qu'eux???
Heu... En ce qui concerne Python, je veux bien que tu me dises quel GUI
Non, je pensais que l'interfacage entre la partie calcul
et la partie réseau d'un programme étaite de même nature
qu'entre la partie calcul et l'IHM, donc un problème qui
n'était pas du domaine que c'était donné C++.
Non, je pensais que l'interfacage entre la partie calcul
et la partie réseau d'un programme étaite de même nature
qu'entre la partie calcul et l'IHM, donc un problème qui
n'était pas du domaine que c'était donné C++.
Non, je pensais que l'interfacage entre la partie calcul
et la partie réseau d'un programme étaite de même nature
qu'entre la partie calcul et l'IHM, donc un problème qui
n'était pas du domaine que c'était donné C++.
Oui, utiliser l'API GUI Windows ou X11/Xlib dans un programme C++ est
une horreur.
Oui, utiliser l'API GUI Windows ou X11/Xlib dans un programme C++ est
une horreur.
Oui, utiliser l'API GUI Windows ou X11/Xlib dans un programme C++ est
une horreur.
