En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
Marc Boyer wrote:En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Alors, la réponse est simple : il n'existe pas de norme pour
l'utilisation des sockets en C++, et la norme pour leur
utilisation en C se limite qu'à un des plateformes qui les
supportent. D'où l'intérête de :
-- un « binding » C++, et
-- qui fasse partie de la norme C++, et non que de une norme
qui ne s'applique qu'à une seule des systèmes d'exploitation
qui les supportent.
Répondre aux question avec « Posix existe » est vraiment
trollasque, puisque franchement, je ne peux pas concevoir que tu
n'es pas au courant qu'il existe des systèmes non-Posix ;
vue le
niveau de tes postings en général, j'ai aussi du mal à penser
que crois aussi que la norme Posix s'interface bien avec le C++
(même en se limitant à ce qui concerne les sockets).
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
C'est que si je définis mes propres classes à moi, mes
fournisseurs ne vont pas les connaître. Et que si tous mes
fournisseurs ont leurs propres classes, ça va être bigrement
difficile à les faire communiquer.
Et je signale que le problème existe aujourd'hui avec les
chaînes : tous les grands fournisseurs de bibliothèque ont
défini les leurs, et ça pose pas mal de problèmes.
Marc Boyer wrote:
En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Alors, la réponse est simple : il n'existe pas de norme pour
l'utilisation des sockets en C++, et la norme pour leur
utilisation en C se limite qu'à un des plateformes qui les
supportent. D'où l'intérête de :
-- un « binding » C++, et
-- qui fasse partie de la norme C++, et non que de une norme
qui ne s'applique qu'à une seule des systèmes d'exploitation
qui les supportent.
Répondre aux question avec « Posix existe » est vraiment
trollasque, puisque franchement, je ne peux pas concevoir que tu
n'es pas au courant qu'il existe des systèmes non-Posix ;
vue le
niveau de tes postings en général, j'ai aussi du mal à penser
que crois aussi que la norme Posix s'interface bien avec le C++
(même en se limitant à ce qui concerne les sockets).
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
C'est que si je définis mes propres classes à moi, mes
fournisseurs ne vont pas les connaître. Et que si tous mes
fournisseurs ont leurs propres classes, ça va être bigrement
difficile à les faire communiquer.
Et je signale que le problème existe aujourd'hui avec les
chaînes : tous les grands fournisseurs de bibliothèque ont
défini les leurs, et ça pose pas mal de problèmes.
Marc Boyer wrote:En ce qui concerne les sockets, je ne suis pas sur que
le besoin soit pattent: POSIX existe, s'interface bien
avec C++.
Je me démande s'il vaut même la peine de réagir à une bêtise
aussi grosse. Je crois qu'il s'agit plutôt d'un troll.
Heuh, non. D'une naïveté que tu peines à imaginer
peut-être, mais je ne voulais pas faire le Troll.
Alors, la réponse est simple : il n'existe pas de norme pour
l'utilisation des sockets en C++, et la norme pour leur
utilisation en C se limite qu'à un des plateformes qui les
supportent. D'où l'intérête de :
-- un « binding » C++, et
-- qui fasse partie de la norme C++, et non que de une norme
qui ne s'applique qu'à une seule des systèmes d'exploitation
qui les supportent.
Répondre aux question avec « Posix existe » est vraiment
trollasque, puisque franchement, je ne peux pas concevoir que tu
n'es pas au courant qu'il existe des systèmes non-Posix ;
vue le
niveau de tes postings en général, j'ai aussi du mal à penser
que crois aussi que la norme Posix s'interface bien avec le C++
(même en se limitant à ce qui concerne les sockets).
Ca s'interface bien ? A quel coût ? As tu déja crée tes
propres classes d'encapsulation des sockets ?
Ce coût est-il si dissuadant que ca ?
Le coût, c'est que je ne peux pas utiliser mes classes dans
les interfaces avec d'autres bibliothèques. C'est un coût
énorme, prohibitif même. (Régarde tous les problèmes qu'on a
avec std::string et les bibliothèques qui précède la norme.)
Je ne comprends pas ta remarque. Je dois être très à côté
de la plaque sur cette question.
C'est que si je définis mes propres classes à moi, mes
fournisseurs ne vont pas les connaître. Et que si tous mes
fournisseurs ont leurs propres classes, ça va être bigrement
difficile à les faire communiquer.
Et je signale que le problème existe aujourd'hui avec les
chaînes : tous les grands fournisseurs de bibliothèque ont
défini les leurs, et ça pose pas mal de problèmes.
J'aurais pu préciser ma pensée: en se limitant aux sockets
(et uniquement à ça), on à une interface socket quasi-POSIX,
qu'on attaque en C++ comme en C. C'est pas idéal, mais c'est
pas pire.
Après, en effet, si on essaye de faire mieux que le
simple flux de char*, il existe tellement de directions
d'extensions que les variations sont immenses.
J'aurais pu préciser ma pensée: en se limitant aux sockets
(et uniquement à ça), on à une interface socket quasi-POSIX,
qu'on attaque en C++ comme en C. C'est pas idéal, mais c'est
pas pire.
Après, en effet, si on essaye de faire mieux que le
simple flux de char*, il existe tellement de directions
d'extensions que les variations sont immenses.
J'aurais pu préciser ma pensée: en se limitant aux sockets
(et uniquement à ça), on à une interface socket quasi-POSIX,
qu'on attaque en C++ comme en C. C'est pas idéal, mais c'est
pas pire.
Après, en effet, si on essaye de faire mieux que le
simple flux de char*, il existe tellement de directions
d'extensions que les variations sont immenses.
"Fabien LE LEZ" a écrit dans le message de
news:Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un
contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune
manière de savoir quand un destructeur va être appelé. D'ailleurs, comme
un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se
démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été
détruit, ce qui peut créer des problèmes. On peut le résoudre dans la
plupart des cas en disciplinant son code, ou encore avec des pointeurs
intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau
pour la standardisation, ça?).
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de
news: eq4oc19aopdql842hnn63st8ln7n7pj9tm@4ax.com...
Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un
contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune
manière de savoir quand un destructeur va être appelé. D'ailleurs, comme
un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se
démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été
détruit, ce qui peut créer des problèmes. On peut le résoudre dans la
plupart des cas en disciplinant son code, ou encore avec des pointeurs
intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau
pour la standardisation, ça?).
"Fabien LE LEZ" a écrit dans le message de
news:Des concepts comme le GC ne datent pas d'hier et de nombreux
langage en disposent.
Mais toute la philosophie du C++ est (ou me semble être) justement
contraire à l'idée de GC : on crée un objet, il est automatiquement
détruit en fin de bloc (ni avant, ni après), et tout va bien.
Moins bien avec l'usage de new.
L'une des raisons principales d'utiliser new/delete, c'est d'avoir un
contrôle fin sur la désallocation, justement. Avec un GC, il n'y aucune
manière de savoir quand un destructeur va être appelé. D'ailleurs, comme
un fait exprès, Java n'a pas de destructeur. Je ne sais pas comment se
démerde C#, d'ailleurs, à ce sujet.
Certes, le C++ permet de garder un pointeur sur un objet qui a été
détruit, ce qui peut créer des problèmes. On peut le résoudre dans la
plupart des cas en disciplinant son code, ou encore avec des pointeurs
intelligents comme boost::shared_ptr (est-ce que c'est dans le tuyau
pour la standardisation, ça?).
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait
des new, c'est un peu comme si on avait un GC non?
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait
des new, c'est un peu comme si on avait un GC non?
Si on utilise des shared_ptr systematiquent chaque fois qu'on fait
des new, c'est un peu comme si on avait un GC non?
Anthony Fleury wrote:
Et alors ? parce que c'est disponible dans d'autres langages
on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis
des autres programmeurs C++ ou si la majorité est contre moi,
mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai
une variable en C++, je sais qu'elle sera détruite à la fin du
bloc si c'est une variable automatique, à la fin du programme
si c'est une static, et quand je vais faire un delete pour une
variable allouée dynamiquement.
Et alors ? Quel rapport avec un glaneur de cellules ? La
présence ou l'absence d'un glaneur de cellules ne change
absolument rien en ce qui concerne les variables automatiques ou
statiques, ni en ce qui concerne le fonctionnement de delete.
Pour l'instant, je ne crois pas qu'il y a un consensus en ce qui
concerne la façon exacte que le GC s'integrera dans le C++, mais
ce qui est certain, c'est qu'il ne changera pas la sémantique
des programmes existants. À moins qu'ils ont des fuites de
mémoire, évidemment.
Pourquoi avoir un GC ??
Pour réduire la quantité de travail nécessaire pour écrire un
programme correct.
(enfin perso si il est inclut ca me plairait de récupérer le
comportement normal de mon compilateur C++)
La compatibilité avec l'existant me semble essentielle. La
possibilité de ne pas utiliser le GC aussi ; il existe des
applications où il ne convient pas (même si elles sont moins
nombreuses qu'on pourrait le croire).
et requiert-il vraiment que des concepts comme les sockets
soient inclus dans la bibliothèque standard d'un langage qui
se veut plus général que ca ?
Oui et non. Disons que l'argument est à peu près le même que
pour des entrées/sorties sur fichier. On pourrait bien imaginer
un langage qui ne supporte ni l'un ni l'autre.
Anthony Fleury wrote:
Et alors ? parce que c'est disponible dans d'autres langages
on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis
des autres programmeurs C++ ou si la majorité est contre moi,
mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai
une variable en C++, je sais qu'elle sera détruite à la fin du
bloc si c'est une variable automatique, à la fin du programme
si c'est une static, et quand je vais faire un delete pour une
variable allouée dynamiquement.
Et alors ? Quel rapport avec un glaneur de cellules ? La
présence ou l'absence d'un glaneur de cellules ne change
absolument rien en ce qui concerne les variables automatiques ou
statiques, ni en ce qui concerne le fonctionnement de delete.
Pour l'instant, je ne crois pas qu'il y a un consensus en ce qui
concerne la façon exacte que le GC s'integrera dans le C++, mais
ce qui est certain, c'est qu'il ne changera pas la sémantique
des programmes existants. À moins qu'ils ont des fuites de
mémoire, évidemment.
Pourquoi avoir un GC ??
Pour réduire la quantité de travail nécessaire pour écrire un
programme correct.
(enfin perso si il est inclut ca me plairait de récupérer le
comportement normal de mon compilateur C++)
La compatibilité avec l'existant me semble essentielle. La
possibilité de ne pas utiliser le GC aussi ; il existe des
applications où il ne convient pas (même si elles sont moins
nombreuses qu'on pourrait le croire).
et requiert-il vraiment que des concepts comme les sockets
soient inclus dans la bibliothèque standard d'un langage qui
se veut plus général que ca ?
Oui et non. Disons que l'argument est à peu près le même que
pour des entrées/sorties sur fichier. On pourrait bien imaginer
un langage qui ne supporte ni l'un ni l'autre.
Anthony Fleury wrote:
Et alors ? parce que c'est disponible dans d'autres langages
on devrait l'ajouter dans C++ ? Je ne sais pas si c'est l'avis
des autres programmeurs C++ ou si la majorité est contre moi,
mais pour ma part je ne veux pas d'un GC dans C++. Quand j'ai
une variable en C++, je sais qu'elle sera détruite à la fin du
bloc si c'est une variable automatique, à la fin du programme
si c'est une static, et quand je vais faire un delete pour une
variable allouée dynamiquement.
Et alors ? Quel rapport avec un glaneur de cellules ? La
présence ou l'absence d'un glaneur de cellules ne change
absolument rien en ce qui concerne les variables automatiques ou
statiques, ni en ce qui concerne le fonctionnement de delete.
Pour l'instant, je ne crois pas qu'il y a un consensus en ce qui
concerne la façon exacte que le GC s'integrera dans le C++, mais
ce qui est certain, c'est qu'il ne changera pas la sémantique
des programmes existants. À moins qu'ils ont des fuites de
mémoire, évidemment.
Pourquoi avoir un GC ??
Pour réduire la quantité de travail nécessaire pour écrire un
programme correct.
(enfin perso si il est inclut ca me plairait de récupérer le
comportement normal de mon compilateur C++)
La compatibilité avec l'existant me semble essentielle. La
possibilité de ne pas utiliser le GC aussi ; il existe des
applications où il ne convient pas (même si elles sont moins
nombreuses qu'on pourrait le croire).
et requiert-il vraiment que des concepts comme les sockets
soient inclus dans la bibliothèque standard d'un langage qui
se veut plus général que ca ?
Oui et non. Disons que l'argument est à peu près le même que
pour des entrées/sorties sur fichier. On pourrait bien imaginer
un langage qui ne supporte ni l'un ni l'autre.
C'est à dire qu'il rend, pour moi, delete inutile
C'est à dire qu'il rend, pour moi, delete inutile
C'est à dire qu'il rend, pour moi, delete inutile
Ca je comprend. Mais son rôle serait il seulement de remplacer des
outils genre valgrind et donc réduire le temps de développement ?
Ca je comprend. Mais son rôle serait il seulement de remplacer des
outils genre valgrind et donc réduire le temps de développement ?
Ca je comprend. Mais son rôle serait il seulement de remplacer des
outils genre valgrind et donc réduire le temps de développement ?
Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy
:Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas
envisageable en C++, il me semble ?
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid>:
Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas
envisageable en C++, il me semble ?
On Fri, 08 Jul 2005 22:34:49 +0200, Matthieu Moy
:Pas seulement. Avec un language qui implémente les tests de
débordements de tableaux, pas d'algèbre de pointeur et un garbage
collector (et sans doute d'autres conditions que j'oublie)
Mais a priori, même si on lui greffe un GC, tout ça n'est pas
envisageable en C++, il me semble ?
